viernes, 22 de marzo de 2013

Reingeniería de Procesos de negocios

Reingeniería de Procesos de Negocios



El método del Reingeniería del Proceso de Negocio (BPR) es descrito por Hammer y Champy como “la reconsideración fundamental y el reajuste radical de procesos de organización, para lograr la mejoría drástica del desempeño actual en costo, servicios y velocidad”.

En lugar de organizar una empresa en especialidades funcionales (como producción, contabilidad, comercialización, etc.) y observar las tareas que cada proceso realiza, Hammer y Champy recomiendan que debemos observar procesos completos. Desde la adquisición de los materiales, pasando por la producción, la comercialización y la distribución. Uno debe reconstruir la firma en una serie de procesos.
La creación del valor para el cliente es el factor principal para el BPR y las tecnologías de la información a menudo desempeñan un rol importante para lograrlo. Compare con: Marketing Relacional

 

MICHAEL HAMMER Y JAMES CHAMPY

Los autores principales de la reingenieria son Michael Hammer y James Champy. En una serie de los libros incluyendo Reengineering the Corporation, de Reengineering Management, y La Agenda, discuten que se desperdicia demasiado tiempo, pasando procesos de un departamento a otro. Ellos demandan que es de lejos más eficiente designar un equipo que realice todas las tareas de un proceso.

UN ACERCAMIENTO DE CINCO PASOS A  LA REINGENIERÍA DE PROCESOS

Davenport (1992) prescribe un acercamiento de cinco pasos al modelo de Reingeniería de Procesos:
  1. Desarrolle la visión del negocio y los objetivos de proceso: El método del BPR es conducido por una visión de negocio que implica objetivos de negocio específicos, tales como reducción de costos, reducción de tiempos, mejoramiento de la calidad final.
  2. Identifique los procesos del negocio que se reajustarán: la mayoría de las firmas utilizan el acercamiento “de alto impacto” que se centra en los procesos más importantes o los que están en más conflicto con la visión del negocio. Un pequeño número de firmas utilizan el “acercamiento exhaustivo”; éste identifica todos los procesos de la organización y después los prioriza de acuerdo al orden de urgencia del reajuste.
  3. Entienda y mida los procesos existentes: para evitar la repetición de viejos errores y proporcionar una línea base para las mejorías futuras. Compare con: Gerencia Científica
  4. Identifiqúe el soporte de IT(Tecnologías de la Información) necesario: el reconocimiento de las capacidades de las IT puede y debe influenciar el BPR.
  5. Diseñe y construya un prototipo del proceso nuevo: el diseño actual no debe verse como el final del proceso de BPR. Más bien, debe ser visto como un prototipo, con sucesivas iteraciones. La metáfora del prototipo alinea la propuesta de la Reingeniería de Procesos con la entrega rápida de resultados, y con la participación y satisfacción de los clientes.
Como un 6to paso adicional del método del BPR, usted puede encontrar a veces: Adaptar la estructura de organización, y el modelo del gobierno, con el proceso primario rediseñado.

CONDICIONES ECONÓMICAS GENÉRICAS QUE INFLUENCIAN SI EL BPR ES RECOMENDABLE

Aunque es difícil dar el consejo genérico sobre esto, algunos factores que se puedan considerar son:
  • ¿La competencia supera sin problemas a la compañía? Compare con: Turnaround de una Empresa
  • ¿Hay muchos conflictos en la organización?
  • ¿Hay una extremada alta frecuencia de reuniones?
  • ¿Hay un uso excesivo de la comunicación no estructurada? (notas, email, etc)
  • ¿Es posible considerar un acercamiento más contínuo de mejorías graduales, e incrementales? (véase: Kaizen).

CRÍTICOS DEL ACERCAMIENTO DEL BPR

Reingeniería ha ganado una mala reputación porque tales proyectos han dado lugar a menudo a despidos masivos. A pesar del escándalo que rodeó el lanzamiento de la Reingeniería de Procesos, parcialmente debido al hecho que los autores de "Reengineering the Corporation" hayan compraron cantidades enormes de sus propio libro con la finalidad de alcanzar la parte superior del ranking de bestsellers, el método no ha logrado vivido enteramente todas sus expectativas. Las razones principales parecen ser las siguientes:
  • El BPR asume que el factor que limita el desempeño de la organización es la ineficacia de sus procesos. Esto puede o no, ser siempre verdad. El BPR tampoco ofrece ninguna prueba para validar esta asunción.
  • El BPR asume la necesidad de comenzar el proceso de la mejoramiento del desempeño con una “pizarra limpia”, es decir desatiende totalmente el status quo.
  • El BPR no proporciona una manera eficaz de centrarse los esfuerzos de la mejoría en los apremios de la organización. (Según lo hecho por Goldratt en el Teoría Restrictiva).
  • A veces, o quizá absolutamente a menudo, un cambio gradual e incremental (tal como el Kaizen) puede ser un mejor acercamiento.
  • El BPR es culturalmente es negativamente visto como la manera de pensar de EE.UU.. (véase: Dimensiones Culturales)

BPR COMPARADO A KAIZEN

Cuando se compara el Kaizen con el método del BPR es claro que la filosofía Kaizen está más dirigida al hombre, es más fácil poner en ejecución, pero requiere una disciplina de largo plazo, y proporciona solamente una velocidad pequeña de cambio. El acercamiento de la Reingeniería del Procesos, por otra parte, es más dura, orientada a la tecnología, y permite el cambio radical, pero requiere habilidades considerables de gestión del cambio.


BIBLIOGRAFÍA
http://www.12manage.com/methods_bpr_es.html

Ciclo de Vida de Software


Ciclo de vida del software

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren paravalidar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
  • Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
  • Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
  • Diseño general: requisitos generales de la arquitectura de la aplicación.
  • Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
  • Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
  • Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
  • Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
  • Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
  • Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
  • Implementación
  • Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelos de ciclo de vida

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).

Modelo en cascada

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:
ciclo de vida en cascada

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.
Ciclo de vida V

Mantenimiento de Software


Mantenimiento de Software

El Servicio de mantenimiento de software es una de las actividades en la Ingeniería de Software y es el proceso de mejorar y optimizar el software desplegado (revisión del programa), así como también remediar los defectos.

El mantenimiento de software es también una de las fases en el Ciclo de Vida de Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software.

Tipos de Mantenimientos de Software

  • Correctivo : es corregir un problema que tiene un software, ya sea de programas o del sistema operativo ante un funcionamiento incorrecto, deficiente o incompleto. También se puede definir como corrección de fallos detectados durante la explotación. Ejemplo de este mantenimiento, tenemos:
  1. Las actualizaciones que Windows hace para disminuir las vulnerabilidades.
  2. Instalación de software antivirus para corregir daños que hayas sufrido con algún virus.
  3. También implica, buscar información inútil, programas residentes, y demás software que no necesitas o que funciona incorrectamente.
  • Preventivo: el mantenimiento preventivo de software, que es corregir un problema antes que se presente. También es facilitar el mantenimiento futuro del sistema (verificar precondiciones, mejorar legibilidad…).
  • Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
  • Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.

 

Bibliografia 

http://mundokramer.wordpress.com/2011/05/21/tipos-de-mantenimiento-de-software/

http://www.sincows.com/sincows/index.php?option=com_content&view=article&id=70&Itemid=68

  

SOPORTE DE SOFTWARE

SOPORTE DE SOFTWARE

Soporte de Software

El soporte técnico es un rango de servicios que proporcionan asistencia con el hardware o software de una computadora, o algún otro dispositivo electrónico o mecánico. En general los servicios de soporte técnico tratan de ayudar al usuario a resolver determinados problemas con algún producto en vez de entrenar o personalizar.
La mayoría de las compañías que venden hardware o software ofrecen soporte técnico de manera telefónica o en línea. Las instituciones y compañías por lo general tienen sus propios empleados de soporte técnico. Existen a su vez múltiples lugares libres en la web respecto a soporte técnico, en los cuales los usuarios más experimentados ayudan a los novatos.

Tipos de soporte

El soporte técnico se puede dar por distintos tipos de medio, incluyendo el correo electrónico, chat, software de aplicación, faxes, y técnicos, aunque el más común es el teléfono. En los últimos años hay una tendencia a la prestación de soporte técnico en remoto, donde un técnico se conecta al ordenador mediante una aplicación de conexión remota. 

Niveles de soporte

Cuando el soporte está debidamente organizado, se pueden dar varios niveles de soporte, donde el soporte nivel 1 es el que está en contacto directo con el usuario y que soluciona las incidencias triviales, soporte nivel 2, daría soporte al nivel que está por debajo y a este nivel llega la información algo filtrada y así sucesivamente.
El soporte o asistencia técnica está a menudo subdividido en capas, o niveles (tiers), para que así pueda atender de una forma más eficaz y eficiente a una base de negocio o clientes. El número de niveles en los que una empresa organiza su grupo de soporte depende fundamentalmente de las necesidades del negocio, de los objetivos o de la voluntad ya que conllevará la habilidad para servir de forma suficiente a sus clientes o usuarios.
El motivo que justifica prestrar un servicio de asistenca a través de un sistema multinivel en lugar de un grupo general de soporte es proporcionar el mejor servicio posible de la forma más eficiente. El éxito de la estructura organizativa depende enormemente de la capacidad del equipo técnico de comprender su nivel responsabilidad y compromiso, sus compromisos de tiempo de respuesta al cliente y del momento y forma en la que resulta apropiado escalar una incidencia y hacia qué nivel.1
La estructura más generalizada de servicio de asistencia multinivel se conforma sobre tres niveles de soporte.

Costo del soporte técnico

El costo del soporte puede variar. Algunas compañías ofrecen soporte gratuito limitado cuando se compra su hardware o software; otros cobran por el servicio de soporte telefónico. Algunos son gratuitos mediante foros, salas de charla, correo electrónico y algunos ofrecen contratos de soporte Los precios base a nivel mundial son: software o Hardware de 40 a 60 dlls por hora de trabajo. Redes Software o Hardware de 50 a 100 dlls por hora.

BIBLIOGRAFIA
http://www3.uic.com/wcms/WCMS2.nsf/index/Global_Svc_Support_123.html
http://informatica.uc.cl/Asistencia-y-soporte-de-software/

Licenciado, Ingeniero y Técnico

 Licenciado, Ingeniero y Técnico


Licenciado


Licenciado es la condición que alcanza alguien que consigue una licencia. El término se utiliza, por lo tanto, para describir a la persona que completó una licenciatura, un título de carácter universitario al que se accede después de cursar una carrera de entre cuatro y seis años de duración.
De acuerdo a la teoría, el individuo que la obtiene queda habilitado para ejercer una cierta profesión, certificando sus capacidades e idoneidad para la actividad en la cual se ha formado. Por ejemplo: “El equipo ha decidido contratar un licenciado en Psicología para enfrentar el último tramo del torneo”“Mi hijo es licenciado en Ciencias de la Comunicación”“Discúlpeme, licenciado, pero no concuerdo con usted”“Necesitamos un licenciado en Administración de Empresas que nos ayude a salir adelante”.

Cabe resaltar que las licenciaturas pueden presentarse como unidades académicas independientes o estar incluidas dentro de una carrera segmentada. En este último caso, la licenciatura constituye la segunda etapa, periodo o ciclo, tras la diplomatura y previo a los estudios de doctorado o maestría.
Por extensión a esta estructura de formación, en el lenguaje cotidiano, se conoce como licenciado a quien se precia de ser culto, experto o entendido“¡Muy bien, licenciado! Nos acaba de enseñar los secretos del fútbol en apenas diez minutos”“No soporto a Miguel, se cree licenciado en relaciones humanas”.
Licenciado también es la persona que ha sido declarada libre o despedida de una obligación: “El entrenador fue licenciado después de una nueva derrota del equipo”“Los soldados fueron licenciados tras dos meses de conflicto”.
“El Licenciado Vidriera”, por último, es un relato escrito por Miguel de Cervantes Saavedra y publicado originalmente en 1613. El texto forma parte de las “Novelas ejemplares” de Cervantes.
Sobrevalorar un título
Antiguamente este título se obtenía al concurrir a la Escuela Mayor y consistía en una especialización obtenida con unos años más de estudio, posteriores al bachillerato; cabe mencionar que al finalizar éste, una persona ya podía trabajar de forma profesional, pero tenía un título menor que con dicha especialización.
En lo que respecta a las abreviaturas, son: Lic. (para referirse a licenciados de ambos sexos), Lcdo. (para referirse a un licenciado de género masculino) y Lcda. (para referirse a una licenciada).
Por último, cabe mencionar que aquellos ciclos de formación conocidos como Estudios Superiores, tales como diplomaturas, ingenierías y licenciaturas se encuentran dentro de lo que se llama Educación Superior y deben estudiarse en instituciones preparadas para ofrecer dicho programa, las Universidades.
Como pequeña reflexión diremos que desde que somos pequeños se nos educa para ser “alguien en la vida”: se nos dice que podemos serlo si estudiamos mucho y nos convertimos en profesionales y se le da al estudio académico una sobre valoración.
Esto trae como consecuencia que, sin importar las inclinaciones y las pasiones de los individuos, casi todos terminen concurriendo a la universidad para estudiar carreras que prometan una vida laboral estable, convirtiéndose en médicos, abogados, economistas, físicos, etc…
Pero todo esto tiene un inconveniente que para nada es menor, ocasiona que muchas personas sean infelices, porque al descubrir que ni siquiera esa carrera y tener un trabajo estable, les proporciona la dicha de sentirse a gusto consigo mismos, sienten que han perdido el tiempo y que su vida se encuentra vacía. Todo por permitir que ciertas normas, que para algunos son válidas, corrompan su libertad y frustren sus deseos de dedicarse a otra cosa que los completa de verdad.
Obtener una licenciatura puede ser ideal si se desea trabajar como médico o ingeniero, pero lo más importante es tener vocación para ello; es necesario estudiar aquello que realmente nos apasiona e intentar crearnos un futuro que nos haga felices.
Por eso, antes de pensar en la salida laboral que tendremos con tal o cual carrera, conviene pensar qué nos gusta y si realmente necesitamos ir a la Universidad para aprender dicha profesión. Es necesario tener presente que muchísimos grandes en lo suyo han sido autodidactas, por lo que la única opción para aprender no es valiéndose del sistema de educación estandarizado, sino del sistema que mejor se amolde a nuestras posibilidades y necesidades.


INGENIERO




Un ingeniero es una persona con dedicación profesional en un campo de la ingeniería. Los ingenieros se preocupan por el desarrollo de soluciones económicas y seguras a problemas prácticos, mediante la aplicación de las matemáticas y el conocimiento científico teniendo en cuenta las limitaciones técnicas. En este sentido, la labor de los ingenieros es el vínculo entre las necesidades de la sociedad y de las aplicaciones comerciales. Algunos consideran esta profesión como un vínculo entre el arte y la ciencia.

Código de Ética de los Ingenieros

Principios Fundamentales
Los Ingenieros sostienen y avanzan la integridad, honor, y dignidad de la ingeniería como profesión, a través de:
        • Usar sus conocimientos y habilidades para mejorar el bienestar humano.
        • Ser honesto e imparcial, y servir con fidelidad al público, a sus empleados, y a sus clientes.
        • Luchar por aumentar el nivel de competencia y el prestigio de ingeniería como profesión.
        • Apoyar las sociedades profesionales y técnicas de sus respectivas disciplinas.
          Dogmas Fundamentales
                        • El ingeniero deberá de tener en alta prioridad la seguridad, la salud, y bienestar del público cuando ejecute sus funciones de ingeniero.
                        • El ingeniero desarrollará trabajos y servicios solo en las áreas de sus competencia.
                        • El ingeniero dará opiniones y dictámenes de una manera objetiva y veraz.
                        • El ingeniero actuara, en asuntos profesionales para cada empleador o cliente, como un agente o encargado fiel, y evitará conflicto de intereses.
                        • El ingeniero desarrollara su reputación profesional a través de los méritos de su servicios, y no competirá de manera ventajosa con otros.
                        • El ingeniero se asociará solo con personas y organizaciones de buena reputación.
                        • El ingeniero continuará su desarrollo profesional a través de educación continua a lo largo de su profesión, y proveerá con oportunidades de desarrollo profesional a aquellos ingenieros bajo su supervisión.

                        TECNICO


                        El concepto de técnico está vinculado al griego téchne, que puede traducirse como “ciencia” o “arte”. Esta noción hace referencia a un procedimiento que tiene como objetivo la obtención de un cierto resultado o fin. Al ejecutar conocimientos técnicos, se sigue un conjunto de reglas y normas que se utiliza como medio para alcanzar un fin.
                        Técnico
                        Se conoce técnico a aquel que domina una técnica. Puede tratarse de un grado o calificación al que se accede a partir de la educación formal, como en el caso de los técnicos químicos o técnicos en radiología. El técnico conoce diversas herramientas, ya sean intelectuales o físicas, que le permiten ejecutar la técnica en cuestión.
                        El servicio técnico es aquel destinado a solucionar problemas vinculados a equipos electrónicos. Las marcas suelen contar con un servicio técnico oficial que incluso cubre los fallos que se producen durante el periodo de garantía. Existen empresas o profesionales que también ofrecen servicio técnico pero de forma independiente (es decir, solucionan problemas que puedan ocurrir en artefactos de distintas marcas).
                        Por ejemplo: “Tengo que llamar al servicio técnico del aire acondicionado ya que no está enfriando bien”“Hace dos semanas que tengo el televisor en el servicio técnico pero me dicen que aún no logran solucionar el problema”.
                        El director técnico, también conocido como técnico o entrenador, es la persona que se encarga del entrenamiento, la instrucción y la dirección de un deportista o equipo. En el caso del fútbol, el técnico es quien dirige las prácticas y entrenamientos, selecciona a los jugadores, elabora las estrategias, dispone la táctica y ordena los cambios durante los partidos.


                        BIBLIOGRAFIA


                        http://definicion.de/licenciado/
                        http://ayudaelectronica.com/que-es-un-ingeniero/
                        http://definicion.de/tecnico/

                        Casos de Uso


                        CASOS DE USO 

                        Definiciones Básicas
                        Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y
                        alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese
                        momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese
                        caso de uso.

                        El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal
                        objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

                        Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no
                        desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo información de
                        pedidos y no Generando información de pedidos.

                        Los casos de uso tienen las siguientes características:
                        1) Están expresados desde el punto de vista del actor.
                        2) Se documentan con texto informal.
                        3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el
                        énfasis está puesto en la interacción.
                        4) Son iniciados por un único actor.
                        5) Están acotados al uso de una determinada funcionalidad –claramente diferenciada– del sistema.
                        El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene
                        un único caso de uso Usando el Sistema.  Sin embargo, la especificación resultante sería de poco utilidad para
                        entenderlo; sería como implementar un gran sistema escribiendo un único programa.

                        La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por ejemplo, ¿ingresar
                        pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del
                        caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos válidos para cualquiera de
                        las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos.
                        Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser
                        difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por
                        esto se hace importante usar el sentido común en estas decisiones.    Casos de Uso – Un Método Práctico para Explorar Requerimientos
                        Cátedra de Ingeniería del Software I Pág. 6
                        En principio podríamos decir que la regla general es: una función del sistema es un caso de uso si se debe
                        indicar explícitamente al sistema que uno quiere acceder a esa función. Por ejemplo, si uno quiere dar de alta
                        un pedido, accederá a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta
                        un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un
                        pedido es una función que forma parte de un caso de uso mayor: dar de alta un pedido.
                        Esta regla, si bien puede ser útil, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por
                        ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y
                        tienen disponibles funciones para ver el siguiente pedido, el anterior, el último y el primero. El actor debe
                        indicar al sistema que quiere acceder a cada una de esas funciones, y según nuestra regla serían todas ellas
                        casos de uso distintos. Sin embargo, en esta situación es mucho más práctico definir un único caso de uso
                        navegando pedidos, que especificarlos todos como casos de uso distintos.
                        Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que
                        uno está escribiendo el manual del usuario del sistema. A nadie se le ocurriría escribir un manual de usuario
                        con un solo capítulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una
                        especificación con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
                        cantidad de capítulos del manual es variable dependiendo de la persona que lo escriba.
                        Para dar una idea aproximada del nivel de detalle de la división de los casos de uso en casos menores, también
                        podemos pensar que un trabajo práctico de Ingeniería del Software I debiera tener alrededor de 8 casos de uso
                        primarios.
                        Descripción de los Casos de Uso

                        Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que
                        sigue el actor para interactuar con el sistema. A continuación se muestra una parte simplificada de la
                        descripción del caso de uso “Ingresando Pedido”.

                        Caso de Uso: Ingresando Pedido.
                        Actor: Empleado de Ventas.
                        1) El cliente se comunica con la oficina de ventas, e informa su número de cliente
                        2) El oficial de ventas ingresa el número de cliente en el sistema
                        3) El sistema obtiene la información básica sobre el cliente
                        4) El cliente informa el producto que quiere comprar, indicando la cantidad
                        5) El sistema obtiene la información sobre el producto solicitado, y confirma su
                        disponibilidad.
                        6) Se repite el paso 4) hasta que el cliente no informa más productos



                        Relaciones de Extensión
                        Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas
                        oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar
                        pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios.


                        Las extensiones tienen las siguientes características:
                        1) Representan una parte de la funcionalidad del caso que no siempre ocurre.
                        2) Son un caso de uso en sí mismas.
                        3) No necesariamente provienen de un error o excepción. En su libro, Jacobson ejemplifica los casos de uso
                        con ir a cenar a un restaurant. Para él, tomar café después de cenar es un ejemplo de una extensión.

                        La pregunta que surge claramente es ¿cuál es la diferencia entre una alternativa y una extensión? La respuestapuede derivarse de las características de cada uno:

                        · Una extensión es un caso de uso en sí mismo, mientras que una alternativa no.
                        · Una alternativa es un error o excepción, mientras que una extensión puede no serlo.

                        Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. ¿Cómo hago para no repetir el texto de esta
                        funcionalidad en todos los casos de uso que la acceden? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el caso que ‘usa a’ al caso que es ‘usado’.

                        Al modularizar la especificación, identificando relaciones de uso y extensión, puede pasar que extraigamos
                        casos de uso que son accedidos por varios actores. Por ejemplo, el caso de uso buscando datos de producto es accedido por muchos actores (el empleado de ventas que ingresa un pedido, el gerente que quiere obtener estadísticas por producto, el supervisor que quiere consultar la información de algún producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta fuera del contexto de otro caso de uso, decimos que es un caso de uso abstracto. Lo llamamos abstracto porque no es implementable por sí mismo: sólo tiene sentido como parte de otros casos.

                        De la misma forma, el actor que participa de este caso de uso, que reúne características comunes a todos los actores de los casos de uso que lo usan, es un actor abstracto. En nuestro ejemplo, si bien el nombre suena poco elegante, podemos decir que tenemos un actor abstracto “Buscador de Datos de Producto”. Los actores abstractos, entonces, son necesarios para no “dejar sin actores” a los casos de uso abstractos.

                        La duda ahora es cómo relacionar este actor abstracto con los actores concretos: los que sí existen en la
                        realidad y ejecutan casos de uso concretos, como ingresando pedido y obteniendo estadísticas de ventas.
                        Para esto podemos usar el concepto de herencia, uno de los conceptos básicos de la orientación a objetos.
                        Como todos los actores concretos también ejecutan el caso buscando datos de producto, a través de la
                        relación de uso, podemos decir que los actores concretos heredan al actor abstracto.

                        La relación de herencia no necesariamente implica la existencia de un caso abstracto. Puede ocurrir que un
                        actor ejecute todos los casos que ejecuta otro actor, y algunos más. En nuestro sistema, el supervisor de ventas puede hacer todo lo que hace el empleado de ventas, pero además puede autorizar pedidos. En este caso, podemos decir que el Supervisor de Ventas hereda al Empleado de Ventas, aunque el Empleado de Ventas no sea un actor abstracto. De esta forma, toda la funcionalidad que está habilitada para el Empleado de Ventas también lo está para el Supervisor






                        Ingeniería de Procesos


                        Ingeniería de Procesos
                        Se entiende por Ingeniería de proceso aquella que:
                        • Se desarrolla, evalúa y diseña los procesos productivos
                        • Se genera toda la información indispensable para la ingeniería básica
                        • Por Proceso se entiende toda operación de transformación,
                        • Se define el Know how ”como se hace, es la información obtenida de la investigación y desarrollo”
                        • Se definen los requerimientos de materias primas e insumos que tenga el proceso.



                        De qué tarta la ingeniería de procesos?

                                                                                                                                                                                                              Es una rama de la ingeniería con conocimientos suficientes en ciencia y tecnología, para
                        aplicarlas en el diseño, simulación, optimización, innovación, logística y gestión de los
                         procesos, con base en el estudio de aquellos de naturaleza fisicoquímica y biotecnológica,
                        Y una ética empresarial que promueva la protección del ambiente y la seguridad industrial.







                        Qué hace un ingeniero de procesos?

                        La misión fundamental del ingeniero de procesos es diseñar, poner en marcha y ejecutar todo lo necesario para obtener la Óptima explotación de los sistemas o procesos a instalar en los departamentos de producción de las empresas industriales.

                         


                        Bibliografía
                        http://www.cocogum.org/Archivos/Ingenieria%20de%20Procesos.html
                        http://www.laboris.net/static/ca_profesion_ingeniero-procesos.aspx