ENFOQUE PARA LA ADMINISTRACIÓN DEL PROYECTO.
• El proyecto se desarrollará bajo un plan cuyo formato será aprobado por ambas partes.
• Se contará con un líder de proyecto que responderá directamente ante el representante de la organizacióncliente que se designe.
• Se definirán los entregables claves y sus puntos de control. Los mismos deberán ser aprobados y autorizadospor el líder del proyecto y el representante del cliente.
• Se requerirá la aprobación de los resultados de un incremento para avanzar al siguiente.
Estándares
• Se emplearán los estándares de documentación empleados en los proyectos similares que ha desarrollado elITESO.
• El modelado se hará en UML.
METODOLOGÍA PARA EL DESARROLLO DEL SOFTWARE
Está basada en:
• Ciclos incrementales e iterativos.
• Uso de estándares de documentación.
• Estrecha y sistemática interacción con el cliente.
• Los métodos, técnicas y herramientas del análisis, diseño y construcción orientados a objetos.
• Enfoque centrado en los clientes, los cuales tomarán parte activa en el desarrollo del software.
BENEFICIOS PARA EL CLIENTE
• Reducción de tiempo dedicado a los conteos cíclicos.
• Disminución del desperdicio de materiales.
• Información confiable y disponible para la toma de decisiones.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
2 mar 2009
INVESTIGACION PRELIMINAR
Por cualquiera que sea la estrategia mediante la cual se va a desarrollar el sistema (SDLC, prototipos, análisis estructurado, o por una combinación de éstos) primero es necesario revisar la solicitud del proyecto. La elección de una estrategia es secundario, lo importante es determinar si la solicitud merece o no la inversión de recursos en un proyecto de sistemas de información. El tiempo estimado es aproximadamente entre 4 a 6 seis días.
El propósito de la investigación preliminar es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación preliminar debe cumplir con los siguientes cinco objetivos:
1. Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, o sea, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer. La limitación puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – y los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
El propósito de la investigación preliminar es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación preliminar debe cumplir con los siguientes cinco objetivos:
1. Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, o sea, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer. La limitación puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – y los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
ESTUDIO DE FACILIDAD
En primer lugar, la arquitectura del equipo que analizamos, esto implica evaluar cual es la arquitectura que mejor se adapta para el procesamiento de las aplicaciones que pensamos desarrollar en nuestro futuro equipo.
En este punto, debemos evaluar la filosofía con que fue construida la computadora y la orientación técnica de sus componentes, en relación con el tipo de procesamiento para el que fue pensado originalmente.
Según la filosofía de su construcción, el procesamiento puede ser: centralizado, descentralizado o distribuido, y de acuerdo a la envergadura de algunas compañías, una mezcla e ellos.
La complejidad que presenta la evaluación de un proyecto de inversión como la toma de un computador, impone la utilización de una metodología que establezca una disciplina de trabajo que permita el planeamiento y control del proyecto, facilite la asignación de tareas y mejorar las estimaciones, y en definitiva nos permita reducir el riesgo.
En el presente trabajo se formula una metodología para efectuar un Estudio de Factibilidad para la toma de un computador que contempla los aspectos mencionados anteriormente, si bien este no es el único proyecto de inversión en informática que requerirá ser evaluado, también se pueden dar los siguientes casos:
Reemplazo del actual computador
Reestructuración del área de sistemas
Revisión parcial de la instalación
Procesamiento de determinadas aplicaciones
Aplicaciones especificas (Robótica, Sistemas Expertos, etc.)
En cada caso, se deberá evaluar que etapas y fases de la metodología se deberán utilizar, pero el común denominador será que el Estudio de Factibilidad tiene por objeto transformar un acto aventurado de inversión, en una decisión de riesgo calculado.
La ausencia de una metodología se debe más a la falta de apreciación del riesgo involucrado, que a la dificultad para su formulación y posterior ejecución.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
En este punto, debemos evaluar la filosofía con que fue construida la computadora y la orientación técnica de sus componentes, en relación con el tipo de procesamiento para el que fue pensado originalmente.
Según la filosofía de su construcción, el procesamiento puede ser: centralizado, descentralizado o distribuido, y de acuerdo a la envergadura de algunas compañías, una mezcla e ellos.
La complejidad que presenta la evaluación de un proyecto de inversión como la toma de un computador, impone la utilización de una metodología que establezca una disciplina de trabajo que permita el planeamiento y control del proyecto, facilite la asignación de tareas y mejorar las estimaciones, y en definitiva nos permita reducir el riesgo.
En el presente trabajo se formula una metodología para efectuar un Estudio de Factibilidad para la toma de un computador que contempla los aspectos mencionados anteriormente, si bien este no es el único proyecto de inversión en informática que requerirá ser evaluado, también se pueden dar los siguientes casos:
Reemplazo del actual computador
Reestructuración del área de sistemas
Revisión parcial de la instalación
Procesamiento de determinadas aplicaciones
Aplicaciones especificas (Robótica, Sistemas Expertos, etc.)
En cada caso, se deberá evaluar que etapas y fases de la metodología se deberán utilizar, pero el común denominador será que el Estudio de Factibilidad tiene por objeto transformar un acto aventurado de inversión, en una decisión de riesgo calculado.
La ausencia de una metodología se debe más a la falta de apreciación del riesgo involucrado, que a la dificultad para su formulación y posterior ejecución.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
TOMA DE DECISIONES
Para la toma de decisiones sabemos que es necesario hacer uso de la información como, el uso de teorías, que tiene como consecuencia el acierto, la incertidumbre y el riesgo, es por eso que debemos diferenciar si el tomador de decisiones en analítico o heurístico y es importante que estos tomen en cuenta las fases de solución como son la inteligencia, la selección y el diseño, tal como se le da soporte en los sistemas de apoyo a decisiones.
LA TOMA DE DECISIONES BAJO RIESGO
Las decisiones son tomadas por lo general bajo tres condiciones importantes como lo es la: certidumbre, incertidumbre y el riego.
La certidumbre es aquella que nos muestra todo por anticipado antes de la decisión, los resultados, las consecuencias y según sean las necesidades presentadas por el usuario.
La incertidumbre es lo contrario de la certidumbre, no tenemos resultados, ni probabilidades o las consecuencias de las decisiones.
Entre estos dos aspectos o condiciones tienen por medio el riesgo, es decir que tenemos el conocimiento (certidumbre) de las alternativas (variables controlables), existen sólo las estimaciones y no está en nuestras manos el controlar (variables ambientales) y de las que no estamos seguros de su resultado (variables dependientes). Bajo estas alternativas que tenemos muchas de las tomas de decisiones en las empresas o negocios se realizan bajo riesgo.
EL ESTILO DE LA TOMA DE DECISIONES
Por lo general la información se recolecta, procesa y se usa en forma de parámetro según sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analíticos o heurísticos.
Un tomador de decisiones analítico se apoya en la información que es adquirida y evaluada sistemáticamente para estrechar las alternativas y tomar una selección que esté basada en información. En donde los tomadores de decisiones analíticos valoran la información cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemáticas para el modelo del problema y usan algoritmos para resolverlos.
Un tomador de decisiones heurístico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurística se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solución. Y su apoyo es el sentido común para que los guíe.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
LA TOMA DE DECISIONES BAJO RIESGO
Las decisiones son tomadas por lo general bajo tres condiciones importantes como lo es la: certidumbre, incertidumbre y el riego.
La certidumbre es aquella que nos muestra todo por anticipado antes de la decisión, los resultados, las consecuencias y según sean las necesidades presentadas por el usuario.
La incertidumbre es lo contrario de la certidumbre, no tenemos resultados, ni probabilidades o las consecuencias de las decisiones.
Entre estos dos aspectos o condiciones tienen por medio el riesgo, es decir que tenemos el conocimiento (certidumbre) de las alternativas (variables controlables), existen sólo las estimaciones y no está en nuestras manos el controlar (variables ambientales) y de las que no estamos seguros de su resultado (variables dependientes). Bajo estas alternativas que tenemos muchas de las tomas de decisiones en las empresas o negocios se realizan bajo riesgo.
EL ESTILO DE LA TOMA DE DECISIONES
Por lo general la información se recolecta, procesa y se usa en forma de parámetro según sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analíticos o heurísticos.
Un tomador de decisiones analítico se apoya en la información que es adquirida y evaluada sistemáticamente para estrechar las alternativas y tomar una selección que esté basada en información. En donde los tomadores de decisiones analíticos valoran la información cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemáticas para el modelo del problema y usan algoritmos para resolverlos.
Un tomador de decisiones heurístico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurística se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solución. Y su apoyo es el sentido común para que los guíe.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
REQUERIMIENTOS DE UNSISTEMA
En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
¿QUE ES UN REQUERIMIENTO?
· Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
· Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
· Una condición o capacidad que debe ser conformada por el sistema (RUP).
· Algo que el sistema debe hacer o una cualidad que el sistema debe poseer.
REQUERIMIENTOS EN INGENIERÍA DE SOFTWARE Y SISTEMAS
En ingeniería de sistemas existen tres tipos de requerimientos.
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
CARACTERÍSTICAS
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
· Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
· No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
· Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
· Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
· Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
· Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
· Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema.
Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de
algún modo, pueden sustituir o mapear con esta lista de características.
Análisis de requerimientos
La etapa en que se estudian los requerimientos para verificar que estén correctamente adecuados a las características mencionadas es conocida como Análisis de Requerimientos. En la misma se enfocan e intentan solucionar las deficiencias que los requerimientos puedan tener.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
¿QUE ES UN REQUERIMIENTO?
· Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
· Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
· Una condición o capacidad que debe ser conformada por el sistema (RUP).
· Algo que el sistema debe hacer o una cualidad que el sistema debe poseer.
REQUERIMIENTOS EN INGENIERÍA DE SOFTWARE Y SISTEMAS
En ingeniería de sistemas existen tres tipos de requerimientos.
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
CARACTERÍSTICAS
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
· Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
· No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
· Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
· Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
· Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
· Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
· Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema.
Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de
algún modo, pueden sustituir o mapear con esta lista de características.
Análisis de requerimientos
La etapa en que se estudian los requerimientos para verificar que estén correctamente adecuados a las características mencionadas es conocida como Análisis de Requerimientos. En la misma se enfocan e intentan solucionar las deficiencias que los requerimientos puedan tener.
http://www.chido-lizarraga.blogspot.com/
http://mgsara4c.blogspot.com/
la vida es un ratico
hola a todos mis amigos
ps aki les dejo este blog
k lo cree
con la materia d e diseño
ps espero que esten bien
nos vemos
Suscribirse a:
Entradas (Atom)
