- Proceso de software y su relación con la Gestión de Proyectos
- El cambio en el desarrollo de software desde la gestión de proyectos
- El rol del proceso de negocio de software ante el proceso de software y los proyectos
OBJETIVO
– Conocer el enfoque de proyectos y su relación con los procesos de software.
Proceso de software y su relación con la Gestión de Proyectos
La problemática actual sobre la falta de conexión efectiva entre el dominio del negocio y el tecnológico, es cada día es más notorio. Los procesos de desarrollo de software no suelen estar ligados directamente a aspectos del negocio.1
Para realizar un eficaz desarrollo de software a partir de la definición de procesos de negocio, es necesario crear un contexto de "Negocio Bajo Demanda". Sólo si la organización empresarial y la tecnológica convergen y tienen objetivos comunes, el modelado de procesos del negocio podrá desencadenar un eficaz desarrollo de software dirigido por modelos. Ver figura 3.1 Proceso de software.
Figura 3.1: Proceso de software.
1 SÁNCHEZ Vidales, Miguel Ángel; JOYANES Aguilar, Luis; FERMOSO García, Ana. (2007). Presentación: Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda.
3.1.1. Enfoque MDA – Model Driven Architecture
Utilizando técnicas MDA y tres niveles de abstracción, permite mejorar los procesos de desarrollo de software, iniciándolos desde una perspectiva del negocio. Ver figura 3.2. Enfoque MDA – Model Driven Architecture.
Figura 3.2: Enfoque MDA – Model Driven Architecture.
3.1.1.1. Elementos del MDA
Los elementos que trabajan el MDA se describen a continuación:
a) CIM – Computation Independent Model
Principalmente modelado del dominio (requerimientos), es Independiente de cómo el sistema es implementado utiliza fuente de vocabulario compartido y ayuda a entender que es lo que se quiere que haga el sistema.
b) PIM – Platform Independent Model
PMI es el modelo del sistema de alto nivel (diseño), representa estructura, funcionalidad, restricciones, sin aludir a una plataforma especifica y es base para todo el proceso de desarrollo.
c) PSM – Platform Specific Model
PSM es la vista de un sistema desde el punto de vista de plataforma específica (implementación), representa el mismo sistema pero a diferente nivel de abstracción (es más cercano a la vista de código) y de un PIM pueden obtenerse varios PSMs.
3.1.1.2. ¿Qué es una transformación?
El concepto central de MDA es la generación de un modelo destino desde un modelo fuente, este proceso consiste en reglas (de transformación) que se ejecutan mediante una herramienta (de transformación).
El insumo o entrada para realizar la transformación son el PIM, Marcas y Mapeo. El resultado de la transformación es PSM y Registro de la transformación.
3.1.1.3. ¿Qué son marcas de modelos?
Son anotaciones asociadas a los elementos del modelo que contiene información útil que son entradas adicionales a un modelo que seleccionan que reglas se aplican y las extensiones a un modelo que captura información requerida para la transformación, sin "contaminar" ese modelo. Las características de las marcas no afectan al modelo con especificaciones dependientes de una plataforma, no son parte ni del modelo fuente ni del modelo destino, pueden referenciar elementos de ambos modelos.
3.1.1.4. ¿Qué es un mapeo?
El mapeo es la relación semántica entre modelos que provee especificaciones para la transformación de un PIM a un PSM para una plataforma en particular. El modelo MDA soporta desarrollo de software iterativo e incremental, se pueden repetir los mapeos entre modelos. Ver figura 3.3. Enfoque MDA, transformaciones, marcas y mapeos de modelos.
Figura 3.3: Enfoque MDA, transformaciones, marcas y mapeos de modelos.
3.1.1.5. Extensión MDA – modelos
A continuación se describen las extensiones MDA: Ver figura 3.4 Extensión MDA – Modelos.
– CIM, hace referencia al Modelo CU, al modelo conceptual y especificación de requerimientos.
– PIM hace referencia de la descripción de la arquitectura, modelos de diseño (Diagramas de: Subsistema, clases, colaboración y secuencia) y modelo de datos.
– PIM marcado hace referencia al modelo PIM con estereotipos definidos para cada tecnología de desarrollo.
– PSM es el modelo más cercano al código.
– Código lo generado por la herramienta y lo implementado por el equipo.
Figura 3.4: Extensión MDA – Modelos.
3.1.1.6. Transformación de modelos en el enfoque MDA
En la figura 3.5 se muestra la transformación de diferentes modelos en el enfoque MDA1
Figura 3.5: Transformación de modelos en el enfoque MDA.
A continuación en la tabla 3.1 se muestran las actividades de la transformación de los diferentes modelos en el enfoque MDA. Los objetivos de las diferentes actividades y los resultados a obtener en cada una de las actividades.
ACTIVIDAD | OBJETIVO | RESULTADOS | |
Análisis de la empresa y del negocio inicial. | Obtener la información necesaria sobre el contexto inicial del negocio. | – Objetivos del negocio en el contexto inicial. Ej. Objetivos relacionados con el proceso de envío de notas. – Infraestructura tecnológica inicial. Ej. Relacionada con el Sistema de Gestión Académica UPSA, la Tarjeta Inteligente y el software de envío de notas. – Descripción de los procesos en el negocio inicial. Ej. "Proceso de envío de notas finales".- Reglas del negocio inicial. Ej. Reglas de la guía académica sobre entrega de actas y comunicación de notas. | |
Plan de adecuación a contexto de negocio bajo demanda (NBD). | Definir y ejecutar un plan que permita crear un entorno de Negocio Bajo Demanda. El plan se debe basar en iteraciones. | – Descripción del contexto de NBD.Ej. Incluirá los nuevos proyectos Campus Virtual y MoviUPSA. – Objetivos del NBD. Ej. Mejorar calidad de servicio al alumno respecto a procesos anteriores.- Infraestructura tecnológica en NBD. Ej. Detalles de los nuevos proyectos Campus Virtual y MoviUPSA.- Proyecto piloto. Ej. Plataforma de envío SMS.- Servicios software. Ej. "Enviar SMS". – Evaluación del contexto de NBD. Ej. Resultados que son analizados por responsables del negocio (Secretario General, Vicerrector de comunicación). | |
Definir entorno de desarrollo basado en MDA y SOA. | Que cada empresa defina su propio entorno de desarrollo ajustándose a MDA y SOA. La dificultad de este paso dependerá del entorno inicial de cada empresa. | – Descripción de modelos, lenguajes y transformaciones MDA.- Arquitectura software basada en MDA y SOA. – Proceso de desarrollo inicial. – Proceso de desarrollo basado en MDA. – Herramientas. |
Tabla 3.1. Niveles de capacidad.
A continuación se muestra en la figura 3.6 el modelado y herramientas utilizados para cada uno de los niveles, el nivel CIM, Nivel PIM y PSM.
Figura 3.6: Niveles PIM, Nivel PIM y PSM.
a) BPM (Business Process Management).
Nos ayuda a realizar el análisis, diseño, modelado y optimización de los procesos de negocio de una empresa u organización.
b) SOA (Service Oriented Architecture)
Simplifica la conexión de los servicios del negocio con los servicios de software.
c) On Demand Business ó Negocio Bajo Demanda (NBD).
Contexto que facilita la integración negocio – tecnología con el objetivo de mejorar la competitividad de las empresas
Cada proyecto de desarrollo se asocia a un proceso del negocio como se muestra en la tabla 3.2.
ACTIVIDAD | OBJETIVO | RESULTADOS |
Organización y planificación general.1 | Preparar todas actividades de gestión del proyecto. | – Información de gestión del proyecto- Planificación, estimaciones, riesgos, etc. |
Modelado y especificación de procesos del negocio (Nivel CIM). | Crear el modelo del proceso del negocio a desarrollar indicando sus características más importantes. | – Modelo del negocio (CIM). – Representación gráfica y especificación de características. |
Análisis del software asociado a los procesos (Nivel PIM). | Definición de los modelos de requisitos y análisis del software implicado en el proceso a desarrollar. | – Descripción del proceso a desarrollar. – Información para un correcto análisis y desarrollo del proceso.- Modelo de requisitos y análisis del software (PIM). – En el ejemplo, PIM-1 y PIM-2. |
Pasos finales del proceso de desarrollo. | Diseño, implementación y despliegue de software. Ejecutar, monitorear y revisar procesos. | – Pueden ser realizados siguiendo los métodos propuestos por otros autores. – Monitorizar y supervisar el proceso del negocio para poder aplicar un verdadero Negocio Bajo Demanda. |
1 Carballal Natacha, Rapetti Catalina, Delgado Andrea. (2006). Presentación: Proceso Extensión MDA. |
Tabla 3.2. Procesos de negocios asociados al proceso de desarrollo.
A continuación se muestran en la tabla 3.3 las actividades del proceso de desarrollo, objetivo, entradas, salidas, el rol responsable y roles involucrados.
| ACTIVIDADES | OBJETIVO | ENTRADAS | SALIDAS | ROL RESPONSABLE | ROL INVOLUCRADO |
Requerimientos | R11 -Especificar CIM | Consiste en el modelado del dominio. Es nuclear la especificación de requerimientos, el modelo de casos de uso, y el modelo de dominio con el objetivo de conceptualizar el CIM | Acta de reunión de requerimientos | CIM(Especificación de los requerimientos – Modelo de casos de uso- Modelo de dominio) | Analista | Diseñador de Interfase de Usuario – Resp.SQAResp. Verificación |
Diseño | D6 -Especificar PIM | Consiste en crear un modelo del sistema en alto nivel. Este modelo esta compuesto por: Descripción de la Arquitectura + Modelo de Diseño (diagramas de Subsistemas, Clases, Colaboración, Secuencia) + Modelo de Datos. El diagrama de clases se realiza en UML | CIM (Especificación de los requerimientos – Modelo de casos de uso- Modelo de dominio) | PIM (Modelo de diseño- Descripción de la Arquitectura – Modelo de datos) | Arquitecto | Analista Especialista Técnico |
| D7 – Marcar elPIM | Consiste en agregar estereotipos a los objetos en UML del PIM (o sea, las clases), para que puedan ser transformados automáticamente, dependiendo de la tecnología de desarrollo a utilizar | PIM (Modelo de diseño – Descripción de la Arquitectura – Modelo de datos)-Plantilla de Marcas | Planilla de Marcas – PIM Marcado (PIM con estereotipos) | Arquitecto | Analista Especialista técnico |
Implementación | I8 – Investigar la Herramienta de Desarrollo | Se agrega el estudio de las herramientas necesarias para utilizar la Extensión MDA | No Tiene | No Tiene | Especialista Técnico |
Tabla 3.3. Procesos de desarrollo asociados al proceso.
1 AndroMDA. Modeling for AndroMDA [en línea]. (2009). Enlace web: http://galaxy.andromda.org/docs/modeling.html. [Leído: 10 de enero 2010, 20.00 h GMT+1].
El cambio en el desarrollo de software desde la gestión de proyectos
3.2.1. El análisis funcional en el desarrollo de software
El análisis funcional es una técnica que se utiliza para identificar las competencias laborales inherentes a una función productiva. Tal función puede estar definida a nivel de un sector ocupacional, una empresa, un grupo de empresas o todo un sector de la producción o los servicios. Se pueden desarrollar análisis funcionales con diferentes niveles de inicio: un sector ocupacional (hotelería); ocupaciones transversales a varios sectores (seguridad y salud ocupacional); o una ocupación (reparador de PC). Esto hace evidente la flexibilidad del análisis funcional. Aunque fue diseñado como una herramienta de análisis para una escala amplia, también puede ser útil en el análisis de ocupaciones en determinados subsectores o aun en organizaciones específicas.
El análisis funcional no es, en modo alguno, un método exacto. Es un enfoque de trabajo para acercarse a las competencias requeridas mediante una estrategia deductiva. Se inicia estableciendo el propósito principal de la función productiva o de servicios bajo análisis y se pregunta sucesivamente qué funciones hay que llevar a cabo para permitir que la función precedente se logre.
Es ideal realizarlo con un grupo de trabajadores que conozcan la función analizada. Su valor como herramienta parte de su representatividad. En su elaboración se siguen ciertas reglas encaminadas a mantener uniformidad de criterios. La redacción del propósito principal, propósito clave, o función clave de la empresa, se suele elaborar siguiendo la estructura:
Para SENAI de Brasil, el Análisis Funcional es un método que se inicia con la definición del propósito clave de una empresa y se concluye cuando se definen las funciones productivas más simples -elementos de competencia– que pueden ser realizados por un trabajador. Se ha utilizado para establecer la estructura de una cualificación profesional, partiendo de la identificación de su propósito principal, derivando sucesivamente para las funciones y subfunciones que sean significativas para el logro de ese propósito y llegando de esa forma a los Elementos de Competencia y Criterios de Desempeño.
SENAI utiliza el Análisis Funcional para la determinación de la competencia profesional en un Perfil Profesional y considera que supera el análisis de tareas. El análisis funcional toma en cuenta el contexto de trabajo, los sistemas organizativos, las relaciones funcionales, los resultados de la producción de bienes y servicios y las demandas futuras. Considera que da un nuevo tratamiento a las actividades laborales pues está vinculado a un análisis más amplio de todo el contexto de trabajo no restringido apenas a las tareas.
SENA lo define como "un método de cuestionamiento y de enfoque que permite la identificación del Propósito Clave de la subárea de desempeño, como punto de partida para enunciar y correlacionar las funciones que deben desarrollar las personas para lograrlo, hasta especificar sus contribuciones individuales".1
CONOCER: Para detectar los elementos de competencia que se presentan en una actividad productiva compleja, como las que normalmente se evidencian en las organizaciones productivas, se cuenta con el Análisis de las Funciones o Análisis Funcional que consiste en una desagregación sucesiva de las funciones productivas hasta encontrar las funciones realizables por una persona, que son los elementos de competencia.
El Análisis de las Funciones tiene la finalidad de identificar aquellas que son necesarias para el logro del propósito principal, es decir, reconocer -por su pertinencia.
L. Mertens:2 El análisis funcional ha sido acogido por la nueva teoría de sistemas sociales como su fundamento metodológico técnico. En esa teoría, al análisis funcional no se refiere al "sistema" en sí, en el sentido de una masa, o un estado, que hay que conservar o de un efecto que hay que producir, sino que es para analizar y comprender la relación entre sistema y entorno, es decir, la diferencia entre ambos.
Desde esta perspectiva, los objetivos y funciones de la empresa no se deben formular desde su organización como sistema cerrado, sino en términos de su relación con el entorno. En consecuencia, la función de cada trabajador en la organización debe entenderse no sólo en su relación con el entorno de la empresa, sino que él también constituye subsistemas dentro del sistema empresa, donde cada función es el entorno de otra.
El análisis funcional parte de lo existente como contingente, como probabilidad, y lo relaciona con puntos de vista del problema, que en este caso es un determinado resultado que se espera de la empresa. Intenta hacer comprensible e inteligible que el problema puede resolverse de un modo, o bien de otro. La relación entre un problema y el resultado deseado y la solución del mismo, no se comprende entonces por sí misma; sirve también de guía para indagar acerca de otras posibilidades, de equivalencias funcionales.
El método funcional es un método comparativo; en términos de competencias, analiza las relaciones que existen en las empresas entre resultados y habilidades, conocimientos y aptitudes de los trabajadores, comparando unas con otras.
Reino Unido: El desarrollo de Cualificaciones Profesionales Nacionales en el Reino Unido (4) utilizó como base una estructura de normas de desempeño con cobertura nacional. Las normas describen la competencia requerida en una determinada área y se elaboran a partir del análisis de las funciones ocupacionales. Este enfoque implica la identificación del objetivo fundamental (llamado también propósito clave) del área bajo análisis, (5) para después continuar con la definición de las funciones que habrían de ser desarrolladas a fin de alcanzar tal propósito clave. Esencialmente es un proceso de desagregación que avanza de lo general hacia lo particular. Una vez identificado el propósito clave la desagregación se hace contestando la pregunta: ¿qué hay que hacer para que esto se logre?
Este procedimiento se efectúa hasta llegar al nivel en el que la función a realizar, que responde a la pregunta formulada, puede ser llevada a cabo por una persona. Es ahí cuando aparece la competencia laboral de un trabajador. Normalmente ello ocurre entre el cuarto y quinto nivel de desagregación en el árbol o mapa funcional.
Este análisis se centra en lo que el trabajador logra, es decir en los resultados; nunca en el proceso que sigue para obtenerlos. Esa es su principal diferencia con los análisis de tareas y análisis de puestos.3
1 SENA. Dirección de Empleo, Metodología para la elaboración de normas de competencia laboral, Bogotá. (2003).2 MERTENS, Leonard. Competencia laboral: Sistemas, surgimiento y modelos. Montevideo. Cinterfor/OIT. (1996). 3 HANDLEY, David. El desarrollo del sistema de calificación profesional nacional en el Reino Unido. En: Competencia laboral y educación basada en normas de competencia. México. Limusa editores. (1996).
3.2.2. El análisis de valor en el desarrollo de software
El análisis de valor es un método ordenado y creativo para aumentar el valor de un ítem. Este "ítem" puede ser un producto, un sistema, un proceso, un procedimiento, un plan, una máquina, un equipo, una herramienta, un servicio o un método de trabajo. El "Análisis de valor", denominado también "Análisis funcional", fue creado por L.D. Miles.
El valor de un ítem es el resultado de dividir cuán bien el ítem logra su función por el costo del ítem (en Análisis de valor, la palabra valor no es sólo otra palabra para costo):
valor del ítem= logro de su función/costo
Un ítem que realiza su función mejor que otro, tiene más valor. Entre dos ítems que realizan su función igualmente bien, tiene más valor el que tiene menor costo.
a) Seleccione el ítem a estudiar y organice un grupo de estudio
Para realizar un análisis de valor conviene organizar un grupo de estudio de 4 a 6 personas, que tengan preferiblemente distintos conocimientos y con antecedentes diferentes. Deberán reunirse en un lugar donde no sufran interrupción alguna. Luego seleccionamos el ítem a estudiar. Debe ser un ítem cuyo costo nos parece ser demasiado elevado o que no realice bien su función.
b) Análisis de valor
El analista de valor deberá tener siempre presente las funciones, no los productos, ni las formas o procesos. La función principal es lo que el ítem hace, es lo que alguien quiso lograr al crearlo. Esta función se deberá expresar (en lo posible) con sólo dos palabras, un verbo y un sustantivo.
Si el ítem está compuesto por varias partes, será útil si nos formulamos la pregunta cuál es la función de cada parte y cómo cada una contribuye a la función principal del ítem. Para determinar el valor de los productos es importante no dejarse distraer por simples funciones agregadas, como lo son la goma de borrar en la punta de un lápiz o la parte del refrigerador que elabora cubitos de hielo. Éstas son funciones que han sido agregadas, porque el hacerlo resultó económico o porque fue fácil de realizar. No tienen ninguna relación con la función principal del producto.
c) Formación
Es necesario buscar la función principal y las funciones secundarias de un ítem. Averiguar cuál es el costo de realizar cada función. El analista de valor debe asumir una actitud crítica, agresiva, no conformista, nunca satisfecho con lo que le entregan por el dinero pagado. La primera acción del grupo deberá ser la de reunir toda la información posible sobre el ítem. Consulten al mejor especialista del tema, no a la persona que esté más disponible. Pedir un detalle de los costos. Reunir dibujos, especificaciones y toda información escrita sobre el ítem. No se puede quedar satisfechos con información oral.
Por ejemplo, si se trata de un lápiz: (Este ejemplo, el del lápiz, ya es un ítem de valor elevado).
– ¿Qué es? (un lápiz)
– ¿Para qué sirve? (para hacer trazos permanentes)
– ¿Cuál es su función principal? (hacer trazos, escribir líneas)
– ¿Cuál es el método, el material o el procedimiento usado para realizar la función principal? (grafito y madera)
– ¿Cuáles son las funciones secundarias correspondientes? ("transferir el grafito al papel" y "facilitar el sostén del grafito")
– ¿Cuál es el costo del ítem y cómo podemos trasladar el costo que implica realizar la función principal a cada función secundaria?
– Es necesario comparar los costos con los de otro ítem de función similar ¿cuánto debería costar cada función y cuál debería ser el costo total?
La atención del grupo de análisis de valor debe estar dirigida a la función principal, porque puede ser que las funciones secundarias cambien durante el análisis. El grupo puede elegir funciones secundarias diferentes para realizar la función principal. No es importante si los costos individuales asignados son imprecisos, porque hasta un valor numérico impreciso es mejor que una expresión como "muy costoso" o "de bajo costo". Debe medirse el valor de la manera en que cada función secundaria es realizada, cómo se la materializa:
– ¿Contribuye al valor? (¿Hay algo que no contribuye al valor?)
– ¿Tiene relación el costo con la función realizada?
– ¿Se necesitan todas sus partes, sus elementos, sus procedimientos?
– ¿Hay algo que pueda realizar mejor la misma función?
– ¿Hay alguna pieza estándar, ya en el mercado, que pueda realizar la misma función?
– Es necesario investigar el costo de una función. Verificar qué es lo que se considera como necesario y qué es lo que alguien agregó.
Recordar: Todo aquello que no contribuye a la función principal, sobra, es derroche, y debiera ser eliminado.
d) Creatividad
El ser humano siempre buscó encontrar las condiciones bajo las cuales la mente humana realmente produce ideas originales, un método que ayude a la creatividad. Enumeramos estas condiciones y estos procedimientos a continuación, los que debemos cumplir estrictamente:
1. Anotar la función principal en forma clara y precisa en una hoja o pizarra (verbo y sustantivo), de manera que el grupo pueda fijar su atención en ella. Debe hacerse sin mencionar el objeto físico o el proceso específico (No mencionar funciones secundarias o agregadas).
2. El jefe del grupo dirá: "Ahora comenzamos", y cuando las ideas ya no fluyan tan rápidamente (alrededor de 15 a 20 minutos), dirá: "Ya está".
3. Los miembros del grupo enumerarán en voz alta cualquier solución al problema que se les ocurra. Es muy importante que no analicen sus propios pensamientos o los de los demás. No deberán reírse o reaccionar cuando se señalen ideas exóticas, improbables o sin sentido. No deberán criticar o conversar con los otros. Solamente deben dejar que su imaginación los lleve y dejar que las ideas fluyan. Puede ser que una idea se inspire en una idea previa (el no surgir ideas raras, es un indicio de que los miembros del grupo están analizando y no están realizando una tormenta de ideas).
4. El jefe anotará todas las ideas presentadas en una hoja o en la pizarra.
5. Una vez finalizada la sesión y si hay alguna duda sobre lo que se quería señalar con una idea determinada, el jefe la aclarará con la ayuda de los miembros. No se analizará ni se descartará idea alguna. Con esto finaliza la tormenta de ideas.
e) Evaluación
La evaluación debería hacerse luego de un intervalo, preferentemente alrededor de dos días después de haber realizado la tormenta de ideas, para emitir al grupo de tomar distancia de la sesión y así ser menos involucrados con ideas propias.
El grupo analizará cada idea. Las ideas similares se agrupan. Al hacer la evaluación, no pensar en el porqué la idea no puede funcionar, en el porqué no es una idea posible. Desarrollar cada idea, transformándola en una idea más práctica, haciéndola funcionar mejor. Hacer una estimación muy aproximada del costo de cada idea e investigar cuidadosamente a aquellas ideas que presentan un costo aparentemente bajo. El cancelar una idea debe estar basado en hechos y no en opiniones.
Identificar las "rejas" y eliminarlas con tacto. Las "rejas" son excusas o ideas preconcebidas que no pueden ser sustentadas con números, hechos, información detallada y precisa o evidencia experimental alguna. Hay quienes creen verdaderamente en estos obstáculos o rejas. Muchas veces hay oro detrás de una reja. Ahora seleccionar de dos a cuatro ideas entre las que tienen el costo más bajo.
Se debe obtener información para analizar y desarrollar una idea. No trabajar en forma aislada. Una vez que el grupo haya avanzado todo lo que pudo, contactar a un especialista. Esto puede ser necesario en la selección de ideas y también durante el desarrollo de las mismas. El analista de valor es un coordinador de especialistas, de grupos de expertos de otras compañías (de alguna forma, hay que pagarles a ellas por su contribución).
Se debe obtener información de la mejor fuente posible, no de la más cercana o de la más accesible. No tener en cuenta ninguna respuesta de una persona o especialista que no esté dentro de su especialidad. Consultar especialistas es una manera poderosa de abolir rejas/obstáculos. Evitar generalizaciones. No aceptar información de segunda mano. Pedir copia de los documentos.
f) El desarrollo de las dos a cuatro ideas seleccionadas
Se debe realizar un verdadero esfuerzo en desarrollar las ideas de menor costo que realizan la función principal. Realizar pruebas, prototipos, conseguir ofertas del costo. Estimar los costos de alternativas a corto plazo, de las alternativas a largo plazo y de todas aquellas ideas nuevas que surgen durante la evaluación. Al final del proceso se debería haber identificado la idea de menor costo. Es necesario contestar el siguiente interrogante ¿Gastaría yo mi propio dinero en esta solución? Si la respuesta no es afirmativa es mejor modificar la idea.
g) Recomendación
Si se trabaja en una organización o empresa, asegúrese que la persona realmente interesada en aplicar la solución sea también la que la vea. Debe presentar la solución final en forma escrita sobre una sola hoja de papel, a la persona que luego la ejecutará, con copia al jefe. En esta hoja deberán figurar el ahorro previsto, los costos y un plan detallado de cómo ejecutar la idea. Deberá contener toda la información necesaria para que una persona, que desconoce el tema, pueda entenderlo y aplicarlo. El grupo mismo de análisis de valor no debería implementar la idea, si ésta está fuera de su área normal de trabajo.
h) Ejecución y seguimiento
El análisis de valor no es un método para controlar el trabajo de otros ni de investigar errores. La cantidad de trabajo necesaria para implementar una idea es generalmente mayor que la cantidad de trabajo que se necesita para producirla. Por eso conviene dejar que la persona que implementa la idea se lleve la mayor parte del reconocimiento y del mérito. Esto ayuda a fomentar relaciones excelentes.
Conviene que el grupo que implementa la idea, sea también el que informa sobre los ahorros logrados y, si es posible, sea el que se beneficie de ellos. Si es necesario, se requiere establecer la forma en la cual se controla la implementación y la manera de calcular los ahorros.
3.2.3. El pliego de condiciones
Se denomina pliego de condiciones a un documento contractual, de carácter comprensivo y obligatorio donde se establecen las condiciones o cláusulas que se aceptan en un contrato de obras o servicios, una concesión administrativa, una subasta, etc.
3.2.3.1. Características de los pliegos de condiciones
En un pliego de condiciones se indica cómo y con qué hay que hacer realidad los proyectos de obras y servicios que se contratan. En el Pliego que se concuerda y firma, contiene las relaciones que existirán y que tienen que cumplirse, entre el propietario y el ejecutor de cualquier proyecto, servicio o concesión administrativa. Este documento debe contener toda la información necesaria para que el proyecto llegue a buen fin de acuerdo con los planos constructivos del mismo, indica las condiciones generales del trabajo, la descripción y características de los materiales a utilizar, los planos constructivos, y la localización de la obra o servicio. También señala los derechos, obligaciones y responsabilidades de las partes que lo suscriben. Señala así mismo como se desarrollará el trabajo y como se resolverán los conflictos que puedan surgir.
3.2.3.2. Partes de un pliego de condiciones
Normalmente los pliegos de condiciones de obras se dividen en varias partes, siendo las más usuales las siguientes:
– Pliego de condiciones generales: esta parte del documento debe incluir la descripción general del contenido del proyecto, los criterios o aspectos normativos, legales y administrativos a considerar por las empresas que intervengan, listado de planos que componen el proyecto, etc. En España la normativa que se aplica en los pliegos de condiciones generales es la norma UNE 24042 (ya no está en vigor).
– Pliegos de especificaciones técnicas: dispone de dos apartados perfectamente diferenciados:
– Especificaciones de materiales y equipos: deben estar bien definidos todos los materiales, equipos, máquinas, instalaciones, etc. que se utilizaran en el proyecto. La definición se hará en función de códigos y reglamentos reconocidos. Las especificaciones hacen referencia a Normas y Reglamentos nacionales tipo (UNE, Normas MOPU, NBE, etc.) o internacionales (DIN, ISO, etc.).
– Especificaciones de ejecución: en este apartado del pliego se hace constar como será realizado el proyecto, es decir, su proceso de fabricación o construcción a partir de los materiales que serán utilizados.
– Pliego de cláusulas administrativas: en este apartado del pliego se determina la forma de medir las partes ejecutadas del proyecto, valorarlas y pagarlas.
3.2.3.3. Ejemplo de índice de un pliego de condiciones de una construcción
Definición de las obras y objeto del pliego
– Objeto.
– Definición de las obras.
– Normativa complementaria de aplicación.
– Condiciones Generales.
Ejecución de la obra
– Definición de los precios y medición de la obra.
– Órdenes del contratista.
– Libro de incidencias.
– Materiales.
– Ensayos.
– Precauciones especiales durante la obra.
– Señalización de obra e instalaciones.
– Trabajos nocturnos.
– Tratamiento de las modificaciones.
– Trabajos no autorizados y defectuosos.
– Responsabilidades especiales del contratista.
Condiciones de la garantía y recepción de las obras.
Condiciones técnicas particulares de los materiales a ejecutar.
– Condiciones generales para todos los materiales: Áridos para morteros y hormigones: morteros, cementos, yesos, agua, piedra para fábricas de obra, hormigones, acero redondo para armaduras, madera, materiales cerámicos, firmes para viales, geotextiles y geomembranas.
El rol del proceso de negocio de software ante el proceso de software y los proyectos
Cuando se relacionan proceso de software y gestión de proyectos, aparece un natural enriquecimiento, por un lado, del proceso de software y, por otro lado, de la gestión de proyectos. El primero incluye elementos de gestión y el segundo incluye rasgos específicos de la producción de software. Este enriquecimiento facilita la concreción y la formalización de un proceso de negocio de software pues aparecen de manera más natural elementos de gestión.
Enviado por:
Lic. Rafael González Freites pepelo
Azua, Republica Dominicana