PLANEACION DE UNA ESTRUCTURA ORGANIZACIONAL

Slides:



Advertisements
Presentaciones similares
SISTEMAS II CICLO DE VIDA.
Advertisements

MODELOS ORIENTADOS A OBJETOS
PLANIFICACIÓN DE TESTING
Proceso de desarrollo con UML y el modelo CMM
Fundamentos de Diseño de Software INFT.1
Lenguaje Unificado de Modelado
Diagnóstico de la Organización de la Calidad PDVSA
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
SISTEMAS II CICLO DE VIDA.
SYSMOTORFLOW PRESENTACIÓN DEL PROCESO Proyecto de Ingeniería de Software 2010.
BizAgi - Business Agility
2. Diseño y Desarrollo del Producto
10º2 Sergio Posso. Jonatán Agualimpia. Julia Blandón. Docente:
Fundamentos de la Gestión de Proyectos
¿Qué es RUP? RUP es un proceso de desarrollo de software: Objetivos:
Proyecto: Lanzamiento
Administración de Procesos de Pruebas
Ingeniería del Software
M.S.C. Ivette Hernández Dávila
Unified Modeling Language (Lenguaje de Modelamiento unificado)
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
Universidad Rey Juan Carlos
Metodología para el desarrollo de Software educativo POO
CONCEPTOS BÁSICOS Diseño de Sistemas.
SISTEMAS II CICLO DE VIDA.
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Ingeniería del Software
VII Congreso de Expotecnología UVM 2007 Jonás A. Montilva C.
Ximena Romano – Doris Correa
Importancia en la efectividad del:
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
Ingeniería de Software I
Rational Unified Process
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
Saber que cambiar y como hacer que el cambio finalmente ocurra será fuente de ventajas competitivas para la compañía. La totalidad de presentaciones y.
El rol de SQA en PIS.
ASIGNACIÓN DE ROLES.
INGENIERIA DE SOFTWARE
Diseño de Sistemas.
Ciclo de vida de un sistema
Gestión de Proyectos De Software
Roles de Open UP.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
MODELAMIENTO VISUAL Y UML
DISEÑO CURRICULAR Presentado por: Cesar Augusto Sáenz María Alejandra Hernández 1.contenidos curriculares de competencia.
Relación con otras asignaturas del plan de estudio
Introducción al proceso de verificación y validación.
Actividades en el Proceso de desarrollo de Software
Estructurar tus ideas para hacerlas realidad
REVISION Y AUDITORIA.
Proceso de desarrollo de Software
CONCEPTO DE CICLO DE VIDA 1 En los departamentos de Sistemas se debe definir un marco de referencia común que debe ser:  Pueda ser empleado por todos.
Evolución y comportamiento del Sector TICs Praxis & Technology Group PraTech METODOLOGÍA DE CALIDAD.
Las fases del ciclo de la vida de desarrollo de sistemas
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
UNIVERSIDAD LATINA (UNILA)
Autor: Reinozo Cuesta Christian Marcelo
Software de Comunicaciones
Motor de generación de Formularios para Infocorp (MOGEFI) Evaluación del Proyecto.
Bachillerato Ingeniería en Informática Fundamentos de Computación.
Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad.
Sobre el Proceso Racional Unificado RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué.
Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el monitoreo constante del proyecto. Consiste esencialmente en.
Reorganización de la Dirección de Servicios de Información Administrativa (propuesta)
1 CICLO DE VIDA. 2 CICLO DE VIDA DE Los Sistemas de Información “ Es un proceso por el cual los analistas de sistemas, los ingenieros computacionales,
Entregables del Proyecto
Flujos de Trabajo Fundamentales Proceso Unificado de Desarrollo de Software.
Fase de Inicio Proceso Unificado de Desarrollo de Software.
Transcripción de la presentación:

PLANEACION DE UNA ESTRUCTURA ORGANIZACIONAL UNIDAD 3 Ing. Francisco Mauro Salgado

Contenido Planeación de una estructura organizacional 3.1 Factores a considerar 3.2 Paradigmas organizacionales 3.3 Los actores en proyecto 3.4 Los trabajadores

3.1 Factores a considerar

Factores a considerar para formar Equipos de Software Los siguientes factores deben ser considerados cuando se selecciona la estructura del equipo del proyecto de software... dificultad del problemas a ser resuelto el tamaño de las líneas de código de los programas resultantes o puntos función el tiempo en que el equipo estará junto (tiempo de vida del equipo) el grado de modularidad del problema la calidad y confiabilidad requeridas del sistema a ser construído la rigidez de la fecha de entrega el grado de sociabilidad (comunicación) requerida para el proyecto

Riesgos Asociados a las Personas Cuestionamientos que deben ser resueltos: • ¿está disponible el mejor personal? • ¿el staff tiene las habilidades adecuadas? • ¿hay suficiente personal disponible? • ¿existe el compromiso completo? • ¿habrá gente que trabaje parcialmente? • ¿el staff tiene las expectativas adecuadas? • ¿el staff tiene el suficiente entrenamiento? • ¿podría la respuesta del staff ser baja?

3.2 Paradigmas organizacionales

Paradigmas Organizacionales paradigma cerrado – estructura al equipo a través de una jerarquía de autoridad tradicional paradigma aleatorio – estructura a un equipo de manera dispersa y depende de la iniciativa individual de los miembros del equipo paradigma abierto – estructura al equipo de una manera en la que se llevan a cabo algunos de los controles asociados con el paradigma cerrado pero también mucha de la innovación ocurre cuando se usa el paradigma aleatorio paradigma síncrono – depende de la fragmentación natural de un problema y organiza a los miembros del equipo para trabajar en piezas del problema con poca comunicación activa entre ellos. sugeridos por Constantine (1993)

Distribución del Esfuerzo actividades “front end” comunicación con el cliente análisis diseño revisión y modificación actividades de construcción codificación o generación de código prueba e instalación unitarias, integración caja-blanca, caja-negra regresión 40-50% 15-20% 30-40%

3.3 Los actores

Los Actores Líder de Proyecto (gestor técnico) Productores SQA Productores (trabajadores) Gestor superior (aspectos de negocio) Clientes (requisitos) Representante de usuario (coordinador de usuarios) Usuario final (pruebas)

3.4 Los trabajadores

Trabajadores (Workers) Personas que participan en el proceso Tienen competencias específicas En cada flujo de trabajo Worker

Trabajadores 1. Analista de Sistemas 2. Especificador de Casos de Uso 3. Arquitecto 4. Ingeniero de Casos de Uso 5. Ingeniero de Componentes 6. Integrador de Sistemas 7. Diseñador de Pruebas 8. Ingeniero de Pruebas de Integración 9. Ingeniero de Pruebas del Sistema

Analista de Sistemas Analista de Sistemas Flujos de Trabajo Responsable del conjunto de requisitos modelados en los casos de uso Requisitos funcionales y no funcionales Delimitar el sistema Encontrar actores y casos de uso Asegurar modelos de casos de uso completos y consistentes Elaborar un glosario para mantener la consistencia semántica Dirigir el modelado Coordinar la captura de requisitos Flujos de Trabajo Requerimientos

Especificador de Casos de Uso de C.U. Responsable de la descripción detallada de un caso de uso Establecer una comunicación estrecha y eficaz con los usuarios (directos) Flujos de Trabajo Requerimientos

Diseñador de Interfaces Diseñar las interfaces de usuario Aspecto visual Desarrollar prototipos de interfaces de usuario para algunos casos de uso Flujos de Trabajo Requerimientos

Arquitecto Arquitecto Flujos de Trabajo Requerimientos Análisis Diseño Describir la arquitectura y prioridades del modelo de casos de uso Análisis Garantizar la integridad del modelo de análisis Correcto, consistente y legible Diseño Garantizar la integridad de los modelos de diseño y despliegue Implantación Garantizar la integridad del modelo de implantación Asignar componentes a nodos Flujos de Trabajo Requerimientos Análisis Diseño Implantación

Ingeniero de Casos de Uso de C.U. Análisis Mantener la integridad de las realizaciones de casos de uso Diseño Detallar las realizaciones de casos de uso Verificar la correspondencia entre análisis y diseño Flujos de Trabajo Análisis Diseño

Ingeniero de Componentes Análisis Definir y mantener las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases del análisis Diseño Definir y mantener las operaciones, métodos, atributos, relaciones y requisitos de implantación de una o más clases del diseño Implantación Definir y mantener el código fuente de uno o varios componentes Pruebas Desarrollar componentes de prueba que automatizan algunos de los procedimientos de prueba Flujos de Trabajo Análisis Diseño Implantación Pruebas

Integrador de Sistemas Planificar la secuencia de construcciones necesarias en cada iteración Integrar cada construcción a partir de sus partes implementadas Flujos de Trabajo Implantación

Diseñador de Pruebas Garantizar la integridad del modelo de pruebas Planear las pruebas Establecer objetivos de prueba apropiados Seleccionar y describir casos de prueba y los procedimientos de prueba Flujos de Trabajo Pruebas

Ingeniero de Pruebas de Integración Ing. de Pruebas de Integración Ejecutar las pruebas de integración Verificar el correcto funcionamiento de componentes Documentar los defectos Flujos de Trabajo Pruebas

Ingeniero de Pruebas del Sistema Ing. de Pruebas del Sistema Ejecutar las pruebas del sistema para cada iteración completa Verificar los resultados en conjunto con los usuarios finales Documentar los defectos Facilidad para tener familiaridad con el comportamiento observable del sistema Flujos de Trabajo Pruebas