1. ¿Quién es el analista de sistemas?
El analista de sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales.
Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de sistemas de información computarizados. Esta definición enfatiza un enfoque sistemático y metódico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto especifico creado por un negocio.
2. ¿Cuáles son algunos de los papeles del analista de sistemas?
Se requiere que los analistas de sistemas desempeñen muchos paquetes en el curso de su trabajo. Algunos de estos papeles son:
1. Consultores externos para negocios.
2. Experto de soporte dentro de un negocio.
3. Agente de cambio en situaciones tanto internas como externas.
3. Explique cual es la principal habilidad del analista de sistemas
Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas.
jueves, 31 de mayo de 2012
ACTIVIDAD 6 (sugeridas)
¿Cuáles son las cuatro razones para la adopción de las herramientas CASE?
Las cuatro razones para la adopción de herramientas CASE son:
1. El incremento de la productividad del analista
2. La mejora de la comunicación entre analistas y usuarios
3. La integración de actividades del ciclo de vida y el análisis.
4. La valoración del impacto de los cambios por mantenimiento.
Explique en que consiste la técnica PERT.
despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta critica y el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del proyecto identificación y agilizando las actividades principales.
¿Cómo se determina la factibilidad del proyecto?
Por medio del estudio de factibilidad los analistas de sistemas recopilan datos que permiten a la administración decidir si continúan con un estudio de sistema completo.
Las cuatro razones para la adopción de herramientas CASE son:
1. El incremento de la productividad del analista
2. La mejora de la comunicación entre analistas y usuarios
3. La integración de actividades del ciclo de vida y el análisis.
4. La valoración del impacto de los cambios por mantenimiento.
Explique en que consiste la técnica PERT.
despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta critica y el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del proyecto identificación y agilizando las actividades principales.
¿Cómo se determina la factibilidad del proyecto?
Por medio del estudio de factibilidad los analistas de sistemas recopilan datos que permiten a la administración decidir si continúan con un estudio de sistema completo.
ACTIVIDAD 6 (obligatorias)
Describa cuales son las habilidades del analista de sistemas.
Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional. Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en forma significativa con muchos tipos de gente diariamente, así como habilidades de computación. Para su éxito es necesario que se involucre el usuario final.
Mencione las siete fases secuenciales.
Las siete fases son:
1. Identificación de problemas.
2. Oportunidades y objetivos
3. Determinación de los requerimientos de información
4. Análisis de las necesidades de sistemas
5. Diseño del sistema recomendado
6. Desarrollo y documentación del software
7. Prueba y mantenimiento del sistema e implementación del mismo.
Explique cada una de los tres puntos fundamentales de las organizaciones a considerar cuando se analizan y diseñan sistemas de información.
Concepto de la organización como sistema:
Las organizaciones son sistemas completos compuestos de subsistemas interrelacionados e interdependientes. Además, los sistemas y subsistemas están caracterizados por su ambiente interno, en un continuo que va desde abiertos a cerrados. Un sistema abierto permite el paso libre de recursos (personas, información y materiales) a través de su frontera. Los sistemas cerrados no permiten el libre flujo de entrada o salida.
Los diagramas entidad-relación ayudan a que le analista de sistemas comprenda las entidades y relaciones que comprende el sistema organizacional. Los cuatro tipos diferentes de relaciones en los diagramas E-R son: relación uno a uno, relación uno a muchos, relación muchos a uno y relación muchos a muchos.
Diversos niveles de administración:
Los tres niveles de control administrativo son: operacional, medio y estratégico. El horizonte de tiempo para la toma de decisiones es diferente para cada nivel.
La cultura organizacional general:
Las culturas y subculturas organizacionales son determinantemente importantes sobre la manera en que las personas usan la información y los sistemas de información. Apoyando los sistemas de información y los sistemas de información. Apoyando los sistemas de información en el contexto de la organización como un sistema más grande, es posible darse cuenta que numerosos factores son importantes y deben ser tomados en cuenta cuando se determinen los requerimientos de información y se diseña e implementa los sistemas de información.
Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional. Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en forma significativa con muchos tipos de gente diariamente, así como habilidades de computación. Para su éxito es necesario que se involucre el usuario final.
Mencione las siete fases secuenciales.
Las siete fases son:
1. Identificación de problemas.
2. Oportunidades y objetivos
3. Determinación de los requerimientos de información
4. Análisis de las necesidades de sistemas
5. Diseño del sistema recomendado
6. Desarrollo y documentación del software
7. Prueba y mantenimiento del sistema e implementación del mismo.
Explique cada una de los tres puntos fundamentales de las organizaciones a considerar cuando se analizan y diseñan sistemas de información.
Concepto de la organización como sistema:
Las organizaciones son sistemas completos compuestos de subsistemas interrelacionados e interdependientes. Además, los sistemas y subsistemas están caracterizados por su ambiente interno, en un continuo que va desde abiertos a cerrados. Un sistema abierto permite el paso libre de recursos (personas, información y materiales) a través de su frontera. Los sistemas cerrados no permiten el libre flujo de entrada o salida.
Los diagramas entidad-relación ayudan a que le analista de sistemas comprenda las entidades y relaciones que comprende el sistema organizacional. Los cuatro tipos diferentes de relaciones en los diagramas E-R son: relación uno a uno, relación uno a muchos, relación muchos a uno y relación muchos a muchos.
Diversos niveles de administración:
Los tres niveles de control administrativo son: operacional, medio y estratégico. El horizonte de tiempo para la toma de decisiones es diferente para cada nivel.
La cultura organizacional general:
Las culturas y subculturas organizacionales son determinantemente importantes sobre la manera en que las personas usan la información y los sistemas de información. Apoyando los sistemas de información y los sistemas de información. Apoyando los sistemas de información en el contexto de la organización como un sistema más grande, es posible darse cuenta que numerosos factores son importantes y deben ser tomados en cuenta cuando se determinen los requerimientos de información y se diseña e implementa los sistemas de información.
martes, 29 de mayo de 2012
UML
UML:
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
DIAGRAMA DE ESTADOS:
En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.
DIAGRAMA DE SECUENCIA:
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
DIAGRAMA DE COLABORACIONES:
Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.
DIAGRAMA DE ACTIVIDADES:
En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
El diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
DIAGRAMA DE COMPONENTES:
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
DIAGRAMA DE DISTRIBUCION:
Este tipo de diagramas se enfoca específicamente al hardware de un sistema determinado.
El elemento primordial del hardware es un nodo, que es un nombre genérico para todo tipo de recurso de cómputo.
Para comenzar, se debe saber que un nodo se representa mediante un cubo:
Dentro del cubo se puede introducir información sobre el nodo, que puede ser simplemente texto o inclusive componentes, usando los diagramas de componentes anteriormente ejemplificados. En el ejemplo que se muestra a continuación, puede verse un nodo que tiene componentes de software (Windows, Office e Internet Explorer). Aunque como ya se dijo, los diagramas de distribución se enfocan en la parte de hardware, cada uno de los nodos puede contener otros componentes, incluyendo software, lo cual puede ser especificado en el diagrama.
DIAGRAMA DE CLASES:
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
DIAGRAMA DE OBJETOS:
Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.
Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
DIAGRAMAS ENTIDAD-RELACION:
Es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.
DIAGRAMA DE CASOS DE USO:
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
DIAGRAMA DE ESTADOS:
En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.
DIAGRAMA DE SECUENCIA:
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
DIAGRAMA DE COLABORACIONES:
Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.
DIAGRAMA DE ACTIVIDADES:
En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
El diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
DIAGRAMA DE COMPONENTES:
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
DIAGRAMA DE DISTRIBUCION:
Este tipo de diagramas se enfoca específicamente al hardware de un sistema determinado.
El elemento primordial del hardware es un nodo, que es un nombre genérico para todo tipo de recurso de cómputo.
Para comenzar, se debe saber que un nodo se representa mediante un cubo:
Dentro del cubo se puede introducir información sobre el nodo, que puede ser simplemente texto o inclusive componentes, usando los diagramas de componentes anteriormente ejemplificados. En el ejemplo que se muestra a continuación, puede verse un nodo que tiene componentes de software (Windows, Office e Internet Explorer). Aunque como ya se dijo, los diagramas de distribución se enfocan en la parte de hardware, cada uno de los nodos puede contener otros componentes, incluyendo software, lo cual puede ser especificado en el diagrama.
DIAGRAMA DE CLASES:
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
DIAGRAMA DE OBJETOS:
Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.
Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
DIAGRAMAS ENTIDAD-RELACION:
Es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.
DIAGRAMA DE CASOS DE USO:
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
lunes, 28 de mayo de 2012
AUTOEVALUACION 5
1. ¿Cuál es el objetivo de la ingeniería de la información?
permitir un más fácil y selectivo acceso a los datos, junto a proporcionar una mejor interacción con los sistemas informáticos.
2. ¿Cuál es factor critico para la determinación del éxito o fracaso de los negocios?
Los factores críticos de éxito (FCE) pueden estar unidos a un objetivo o a una meta individual. Si se quiere conseguir un objetivo o una meta debe estar presente un FCE.
El análisis del impacto tecnológico examina los objetivos y las metas y proporciona una indicación de aquellas tecnologías que tendrán un impacto directo o indirecto en el éxito de su consecución. El ingeniero de la información ponderà las siguientes cuestiones:
• ¿Cómo es de crítica la tecnología para el logro de un objetivo de negocio?
• ¿Esta disponible la tecnología actualmente?
• ¿Cómo modificará la tecnología el modo de hacer negocios?
• ¿Cuáles son los costes directos e indirectos?
• ¿Cómo debería el negocio adaptar o extender o objetivos y metas para adecuarse a la tecnología?
3. ¿Qué es un objetivo?
Los objetivos son resultados que una empresa pretende alcanzar, o situaciones hacia donde ésta pretende llegar.
4. ¿Qué es una meta?
es uno de los pasos que se deberán dar para alcanzar tu objetivo
permitir un más fácil y selectivo acceso a los datos, junto a proporcionar una mejor interacción con los sistemas informáticos.
2. ¿Cuál es factor critico para la determinación del éxito o fracaso de los negocios?
Los factores críticos de éxito (FCE) pueden estar unidos a un objetivo o a una meta individual. Si se quiere conseguir un objetivo o una meta debe estar presente un FCE.
El análisis del impacto tecnológico examina los objetivos y las metas y proporciona una indicación de aquellas tecnologías que tendrán un impacto directo o indirecto en el éxito de su consecución. El ingeniero de la información ponderà las siguientes cuestiones:
• ¿Cómo es de crítica la tecnología para el logro de un objetivo de negocio?
• ¿Esta disponible la tecnología actualmente?
• ¿Cómo modificará la tecnología el modo de hacer negocios?
• ¿Cuáles son los costes directos e indirectos?
• ¿Cómo debería el negocio adaptar o extender o objetivos y metas para adecuarse a la tecnología?
3. ¿Qué es un objetivo?
Los objetivos son resultados que una empresa pretende alcanzar, o situaciones hacia donde ésta pretende llegar.
4. ¿Qué es una meta?
es uno de los pasos que se deberán dar para alcanzar tu objetivo
ACTIVIDAD 5 (sugeridas)
Explique que realiza la ingeniería de la información.
La Ingeniería de la información se define como:
La aplicación de una serie de técnicas formales integradas para
el planeamiento, análisis, diseño y construcción de sistemas de
información para la totalidad de una empresa, o un sector
importante de ella.
La ingeniería del software aplica técnicas estructuradas a un
proyecto. La ingeniería de la información aplica técnicas
estructuradas a la empresa, o a un amplio sector de la empresa,
como un todo. Las técnicas de la ingeniería de la información
contienen a las de la ingeniería del software en una forma
modificada.
Dado que una empresa es tan compleja, el planeamiento, análisis,
diseño y construcción para la totalidad de la empresa, no puede
ser logrado sin herramientas automatizadas. La ingeniería de la
información (IE) ha sido definida en referencia a técnicas
automatizadas de la siguiente manera:
Una serie de técnicas automatizadas integradas en las cuales se
construyen modelos de empresas, datos y procesos, de una
manera, basadas en un amplio conocimiento y usadas para crear
y mantener los sistemas de procesamientos de datos.
La Ingeniería de la Información a veces ha sido definida como:
una serie de disciplinas automatizadas hechas para la totalidad de
una organización, para darle la información oportuna a las
personas adecuadas, en el tiempo adecuado.
Explique que se hace durante el análisis del área del negocio.
Durante el AAN, nuestro punto de mira se desplaza de la visión global a la visión de dominio. Para modelar "las complicadas y sutiles maneras en que se relacionan los diferentes aspectos de la información de la empresa", el ingeniero de la información debe describir cómo se usan y transforman los objetos de datos (descritos durante el PEI y refinados durante el AAN) dentro de cada área de negocio y cómo las funciones de negocio y los procesos dentro de cada área de negocio transforman estos objetos de datos. En esencia, se analizan y modelan datos tanto exógenos como endógenos para cada área de negocio.
Para realizar este trabajo, AAN emplea varios modelos diferentes:
Modelos de datos (ahora refinados al nivel de área de negocio).
Modelos de flujo de proceso.
Diagramas de descomposición de procesos.
Una variedad de matrices de referencias cruzadas.
La planeación de la estrategia de la información empieza por la definición de objetivos y metas. Ponga ejemplos de cada uno de los dominios del negocio.
PEI:
metas: llegar a ser la empresa lider en arquitectura de edificios en el area metropolitana.
objetivos: brindar el mejor servicio a nuestros clientes, de tal forma que esten satisfechos con el trato y el trabajo.
FODA:
F: ° tener un buen equipo de trabajo, capaces de realizar un buen trabajo
° buena comunicacion entre contratistas y clientes
° servicios de calidad
° tener las herramientas necesarias para cumplir los objetivos
O: ° posicionamiento de la empresa en un lugar estrategico
° nuevas herramientas de diseño y construccion
° debilitamiento de la empresa lider actual
° buena organizacion interna de la empresa
D: ° falta de personal
° motivacion al personal
° sistemas no actualizados
° lugar de trabajo pequeño
A: ° surgimiento de nuevas empresas
° fortalecimiento de empresas
° falta de personal
° falta de clientes
La Ingeniería de la información se define como:
La aplicación de una serie de técnicas formales integradas para
el planeamiento, análisis, diseño y construcción de sistemas de
información para la totalidad de una empresa, o un sector
importante de ella.
La ingeniería del software aplica técnicas estructuradas a un
proyecto. La ingeniería de la información aplica técnicas
estructuradas a la empresa, o a un amplio sector de la empresa,
como un todo. Las técnicas de la ingeniería de la información
contienen a las de la ingeniería del software en una forma
modificada.
Dado que una empresa es tan compleja, el planeamiento, análisis,
diseño y construcción para la totalidad de la empresa, no puede
ser logrado sin herramientas automatizadas. La ingeniería de la
información (IE) ha sido definida en referencia a técnicas
automatizadas de la siguiente manera:
Una serie de técnicas automatizadas integradas en las cuales se
construyen modelos de empresas, datos y procesos, de una
manera, basadas en un amplio conocimiento y usadas para crear
y mantener los sistemas de procesamientos de datos.
La Ingeniería de la Información a veces ha sido definida como:
una serie de disciplinas automatizadas hechas para la totalidad de
una organización, para darle la información oportuna a las
personas adecuadas, en el tiempo adecuado.
Explique que se hace durante el análisis del área del negocio.
Durante el AAN, nuestro punto de mira se desplaza de la visión global a la visión de dominio. Para modelar "las complicadas y sutiles maneras en que se relacionan los diferentes aspectos de la información de la empresa", el ingeniero de la información debe describir cómo se usan y transforman los objetos de datos (descritos durante el PEI y refinados durante el AAN) dentro de cada área de negocio y cómo las funciones de negocio y los procesos dentro de cada área de negocio transforman estos objetos de datos. En esencia, se analizan y modelan datos tanto exógenos como endógenos para cada área de negocio.
Para realizar este trabajo, AAN emplea varios modelos diferentes:
Modelos de datos (ahora refinados al nivel de área de negocio).
Modelos de flujo de proceso.
Diagramas de descomposición de procesos.
Una variedad de matrices de referencias cruzadas.
La planeación de la estrategia de la información empieza por la definición de objetivos y metas. Ponga ejemplos de cada uno de los dominios del negocio.
PEI:
metas: llegar a ser la empresa lider en arquitectura de edificios en el area metropolitana.
objetivos: brindar el mejor servicio a nuestros clientes, de tal forma que esten satisfechos con el trato y el trabajo.
FODA:
F: ° tener un buen equipo de trabajo, capaces de realizar un buen trabajo
° buena comunicacion entre contratistas y clientes
° servicios de calidad
° tener las herramientas necesarias para cumplir los objetivos
O: ° posicionamiento de la empresa en un lugar estrategico
° nuevas herramientas de diseño y construccion
° debilitamiento de la empresa lider actual
° buena organizacion interna de la empresa
D: ° falta de personal
° motivacion al personal
° sistemas no actualizados
° lugar de trabajo pequeño
A: ° surgimiento de nuevas empresas
° fortalecimiento de empresas
° falta de personal
° falta de clientes
ACTIVIDAD 5 (obligatorias)
Explique porque es importante la información.
La información se ha colocado en un lugar adecuado como recurso principal. Los tomadores de decisiones están comenzando a comprender que la información no es solo un subproducto de la conducción, si no que a la vez alimenta a los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de estos.
Para maximizar la utilidad de información, un negocio la debe manejar correctamente tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de toda información. Aunque la información se encuentra a nuestro alrededor esta no es gratis y su uso es estratégico para posicionar la competitividad de un negocio.
Mencione y explique los objetivos generales de la planeación estratégica de la información.
• Definir los objetivos y metas del negocio que sean estratégico.
proponer los objetivos a cumplir, para poder alcanzar las metas establecidas
• Aislar los factores de éxito critico.
definir el FODA de la empresa
• Analizar el impacto de la tecnología y automatización en las metas y objetivos.
definir que tecnologias nos ayudaran a cumplir el objetivo y la meta de la empresa
• Analizar la información existente para determinar su papel en la consecución de las metas y objetivos.
analizar en que forma nos pueden ayudar las nuevas tecnologias en la empresa
Ha decidido empezar un negocio con envío de ordenes por correo electrónico. Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniería de información. Empiece por el PEI. Construya un sencillo modelo de empresa que incluya un organigrama, esquemas de funciones y de los procesos de negocio y un modelo de datos en el ámbito del negocio.
PEI:
metas: llegar a ser la empresa lider en arquitectura de edificios en el area metropolitana.
objetivos: brindar el mejor servicio a nuestros clientes, de tal forma que esten satisfechos con el trato y el trabajo.
FODA:
F: ° tener un buen equipo de trabajo, capaces de realizar un buen trabajo
° buena comunicacion entre contratistas y clientes
° servicios de calidad
° tener las herramientas necesarias para cumplir los objetivos
O: ° posicionamiento de la empresa en un lugar estrategico
° nuevas herramientas de diseño y construccion
° debilitamiento de la empresa lider actual
° buena organizacion interna de la empresa
D: ° falta de personal
° motivacion al personal
° sistemas no actualizados
° lugar de trabajo pequeño
A: ° surgimiento de nuevas empresas
° fortalecimiento de empresas
° falta de personal
° falta de clientes
La información se ha colocado en un lugar adecuado como recurso principal. Los tomadores de decisiones están comenzando a comprender que la información no es solo un subproducto de la conducción, si no que a la vez alimenta a los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de estos.
Para maximizar la utilidad de información, un negocio la debe manejar correctamente tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de toda información. Aunque la información se encuentra a nuestro alrededor esta no es gratis y su uso es estratégico para posicionar la competitividad de un negocio.
Mencione y explique los objetivos generales de la planeación estratégica de la información.
• Definir los objetivos y metas del negocio que sean estratégico.
proponer los objetivos a cumplir, para poder alcanzar las metas establecidas
• Aislar los factores de éxito critico.
definir el FODA de la empresa
• Analizar el impacto de la tecnología y automatización en las metas y objetivos.
definir que tecnologias nos ayudaran a cumplir el objetivo y la meta de la empresa
• Analizar la información existente para determinar su papel en la consecución de las metas y objetivos.
analizar en que forma nos pueden ayudar las nuevas tecnologias en la empresa
Ha decidido empezar un negocio con envío de ordenes por correo electrónico. Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniería de información. Empiece por el PEI. Construya un sencillo modelo de empresa que incluya un organigrama, esquemas de funciones y de los procesos de negocio y un modelo de datos en el ámbito del negocio.
PEI:
metas: llegar a ser la empresa lider en arquitectura de edificios en el area metropolitana.
objetivos: brindar el mejor servicio a nuestros clientes, de tal forma que esten satisfechos con el trato y el trabajo.
FODA:
F: ° tener un buen equipo de trabajo, capaces de realizar un buen trabajo
° buena comunicacion entre contratistas y clientes
° servicios de calidad
° tener las herramientas necesarias para cumplir los objetivos
O: ° posicionamiento de la empresa en un lugar estrategico
° nuevas herramientas de diseño y construccion
° debilitamiento de la empresa lider actual
° buena organizacion interna de la empresa
D: ° falta de personal
° motivacion al personal
° sistemas no actualizados
° lugar de trabajo pequeño
A: ° surgimiento de nuevas empresas
° fortalecimiento de empresas
° falta de personal
° falta de clientes
miércoles, 23 de mayo de 2012
AUTOEVALUACION 4
1. ¿Cuales son las características del paradigma ciclo de vida clásico?
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
2. ¿En que consiste el paradigma de construcción de prototipos?
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.
3. ¿Cuales son los pasos a seguir en el paradigma espiral?
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
4. ¿Cuáles son las desventajas del modelo DRA?
• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.
5. ¿Cuál es el parádigma de técnicas de cuarta generación?
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
2. ¿En que consiste el paradigma de construcción de prototipos?
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.
3. ¿Cuales son los pasos a seguir en el paradigma espiral?
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
4. ¿Cuáles son las desventajas del modelo DRA?
• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.
5. ¿Cuál es el parádigma de técnicas de cuarta generación?
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.
ACTIVIDAD 4 (sugeridas)
Proporcione cinco ejemplos de desarrollo del software que sean adecuados para construir prototipos. Nombre dos o tres aplicaciones que fueran más difíciles para construir prototipos.
• adecuados para construir prototipos,
1. Sistema para un negocio de venta por internet, como mercado libre.
2. Sistema para administración de una refaccionaria.
3. Sistema de almacenes.
4. Sistemas para tiendas de autoservicio.
5. Sistemas para consultar citas medicas como ISSSTENET.
• Difíciles para construir prototipos
1. Sistemas para dispositivos médicos.
2. Sistemas para aviónica
Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral.
Es también al igual que el anterior un modelo evolutivo
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Que es el analista de sistemas?
El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático.
El diseñador realiza, con base en el análisis, el diseño de la solución
El analista tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.
Hoy en día, estas funciones han quedado claramente obsoletas a pesar de que la categoría profesional sigue existiendo como tal. Los avances de la ingeniería del software en su corta vida han puesto de manifiesto que estas funciones no son suficientes para lograr un mínimo éxito en el desarrollo de software.
Las funciones más relevantes que faltan son:
Dirección (de proyectos), para dirigir los recursos hacia el resultado deseado.
Educción de requisitos, para determinar el comportamiento que se espera del software.
Garantía de calidad, para garantizar las expectativas del cliente.
Diseño, para que exista una mínima certeza de que el software es viable y eficaz con la tecnología existente.
Gestión de configuración, para controlar el caos a medida que el software crece.
Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia específica de esta profesión. En algunas organizaciones (y en algunos países) la profesión ya no existe, siendo sustituida por otras figuras tales como el ingeniero de software, el jefe de proyecto, el modelador de software, o el analista-programador. Esta última figura es muy popular ya que resuelve los típicos problemas de comunicación que existían entre analistas y programadores. Estos problemas se deben a la extrema idealización de la especialización de funciones.
Es deseable también que el analista de sistemas tenga conocimientos -al menos básicos- de usabilidad. Ya que cualquier sistema que no esté al servicio de los usuarios o diseñado pensando en el usuario, no tiene mucho sentido.
Que es el analista-programador?
El Analista Programador es la persona que realiza las funciones de un analista técnico y de un programador; es decir, parte de una información previa recibida del analista funcional, en función de la cual desarrolla las aplicaciones y organiza los datos. Es el perfil más buscado en la actualidad.
En base a sus conocimientos en el o los lenguajes de programación necesarios en cada caso, sintetiza, organiza y lo lleva a la práctica mediante la codificación de la silución. Requiere características de personalidad similares a las de un programador, con mayor visión global y capacidad de análisis y síntesis.
Que es un programador?
Un programador es aquella persona que escribe, depura y mantiene el código fuente de un programa informático, es decir, del conjunto de instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada. La programación es una de las principales disciplinas dentro de la informática. En la mayoría de los países, programador es también una categoría profesional reconocida.
Los programadores también reciben el nombre de desarrolladores de software, aunque estrictamente forman parte de un equipo de personas de distintas especialidades (mayormente informáticas), y siendo que el equipo es propiamente el desarrollador.
El programador se encarga de la implementación de prototipos mediante un lenguaje de programación, que compilados pueda entender la computadora.
Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la especialización de funciones en la empresa. Así, el proceso de producción de software se concibe como un conjunto de tareas altamente especializadas donde está claramente definido el papel de cada categoría profesional:
El analista, tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información.
El programador cuya única función consistía en trasladar las especificaciones del analista en código ejecutable para la computadora. Dichas especificaciones se recogen en un documento denominado cuaderno de carga, medio de comunicación entre ambos. Esto se consideraba un trabajo mecánico y de baja cualificación.
Hoy día se reconoce que este enfoque no es válido para organizar tareas de tipo intelectual, como es el desarrollo de software. De manera que la profesión de programador ha ido evolucionando. Las dificultades de comunicación entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categoría de profesional intermedia, denominada analista-programador. La concepción original del programador ha desaparecido siendo sustituida por la de un profesional mucho más formado y con unas funciones menos "mecánicas".
La profesión de analista también ha evolucionado, surgiendo el concepto diseñador (de software). Esto se debe a los avances de la ingeniería del software donde se reconoce que el análisis es una actividad compleja y distinta del diseño. Escuetamente, el análisis describe el problema (es decir qué hacer) mientras que el diseño describe la solución (cómo hacerlo).
En la mayoría de países industrializados esto ha dado lugar a la categoría profesional del diseñador o arquitecto del software.
• adecuados para construir prototipos,
1. Sistema para un negocio de venta por internet, como mercado libre.
2. Sistema para administración de una refaccionaria.
3. Sistema de almacenes.
4. Sistemas para tiendas de autoservicio.
5. Sistemas para consultar citas medicas como ISSSTENET.
• Difíciles para construir prototipos
1. Sistemas para dispositivos médicos.
2. Sistemas para aviónica
Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral.
Es también al igual que el anterior un modelo evolutivo
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Que es el analista de sistemas?
El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático.
El diseñador realiza, con base en el análisis, el diseño de la solución
El analista tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.
Hoy en día, estas funciones han quedado claramente obsoletas a pesar de que la categoría profesional sigue existiendo como tal. Los avances de la ingeniería del software en su corta vida han puesto de manifiesto que estas funciones no son suficientes para lograr un mínimo éxito en el desarrollo de software.
Las funciones más relevantes que faltan son:
Dirección (de proyectos), para dirigir los recursos hacia el resultado deseado.
Educción de requisitos, para determinar el comportamiento que se espera del software.
Garantía de calidad, para garantizar las expectativas del cliente.
Diseño, para que exista una mínima certeza de que el software es viable y eficaz con la tecnología existente.
Gestión de configuración, para controlar el caos a medida que el software crece.
Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia específica de esta profesión. En algunas organizaciones (y en algunos países) la profesión ya no existe, siendo sustituida por otras figuras tales como el ingeniero de software, el jefe de proyecto, el modelador de software, o el analista-programador. Esta última figura es muy popular ya que resuelve los típicos problemas de comunicación que existían entre analistas y programadores. Estos problemas se deben a la extrema idealización de la especialización de funciones.
Es deseable también que el analista de sistemas tenga conocimientos -al menos básicos- de usabilidad. Ya que cualquier sistema que no esté al servicio de los usuarios o diseñado pensando en el usuario, no tiene mucho sentido.
Que es el analista-programador?
El Analista Programador es la persona que realiza las funciones de un analista técnico y de un programador; es decir, parte de una información previa recibida del analista funcional, en función de la cual desarrolla las aplicaciones y organiza los datos. Es el perfil más buscado en la actualidad.
En base a sus conocimientos en el o los lenguajes de programación necesarios en cada caso, sintetiza, organiza y lo lleva a la práctica mediante la codificación de la silución. Requiere características de personalidad similares a las de un programador, con mayor visión global y capacidad de análisis y síntesis.
Que es un programador?
Un programador es aquella persona que escribe, depura y mantiene el código fuente de un programa informático, es decir, del conjunto de instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada. La programación es una de las principales disciplinas dentro de la informática. En la mayoría de los países, programador es también una categoría profesional reconocida.
Los programadores también reciben el nombre de desarrolladores de software, aunque estrictamente forman parte de un equipo de personas de distintas especialidades (mayormente informáticas), y siendo que el equipo es propiamente el desarrollador.
El programador se encarga de la implementación de prototipos mediante un lenguaje de programación, que compilados pueda entender la computadora.
Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la especialización de funciones en la empresa. Así, el proceso de producción de software se concibe como un conjunto de tareas altamente especializadas donde está claramente definido el papel de cada categoría profesional:
El analista, tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información.
El programador cuya única función consistía en trasladar las especificaciones del analista en código ejecutable para la computadora. Dichas especificaciones se recogen en un documento denominado cuaderno de carga, medio de comunicación entre ambos. Esto se consideraba un trabajo mecánico y de baja cualificación.
Hoy día se reconoce que este enfoque no es válido para organizar tareas de tipo intelectual, como es el desarrollo de software. De manera que la profesión de programador ha ido evolucionando. Las dificultades de comunicación entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categoría de profesional intermedia, denominada analista-programador. La concepción original del programador ha desaparecido siendo sustituida por la de un profesional mucho más formado y con unas funciones menos "mecánicas".
La profesión de analista también ha evolucionado, surgiendo el concepto diseñador (de software). Esto se debe a los avances de la ingeniería del software donde se reconoce que el análisis es una actividad compleja y distinta del diseño. Escuetamente, el análisis describe el problema (es decir qué hacer) mientras que el diseño describe la solución (cómo hacerlo).
En la mayoría de países industrializados esto ha dado lugar a la categoría profesional del diseñador o arquitecto del software.
martes, 22 de mayo de 2012
ACTIVIDAD 4 (obligatorias)
¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?
PARADIGMA DEL MODELO ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS: Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos. Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente.
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Proporcione tres ejemplos de técnicas de 4ª generación.
1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.
Describa el modelo concurrente
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando?
Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
Explique los pasos tradicionales de cualquier modelo
Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
PARADIGMA DEL MODELO ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS: Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos. Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente.
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Proporcione tres ejemplos de técnicas de 4ª generación.
1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.
Describa el modelo concurrente
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando?
Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
Explique los pasos tradicionales de cualquier modelo
Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
lunes, 21 de mayo de 2012
GRAFICA DE GANTT
GRÁFICA DE GANTT:
Es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias.
En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades mínimas de trabajo y los grupos de tareas (llamados summary elements) o las dependencias entre unidades mínimas de trabajo.
Básicamente el diagrama esta compuesto por un eje vertical donde se establecen las actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que muestra en un calendario la duración de cada una de ellas.
Es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias.
En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades mínimas de trabajo y los grupos de tareas (llamados summary elements) o las dependencias entre unidades mínimas de trabajo.
Básicamente el diagrama esta compuesto por un eje vertical donde se establecen las actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que muestra en un calendario la duración de cada una de ellas.
jueves, 17 de mayo de 2012
ACTIVIDAD 3 (cuestionario, entrevista, observacion)
CUESTIONARIO:
El cuestionario que conforma una encuesta estará compuesto por una cantidad determinada de preguntas, las cuales deberán ser formuladas de forma coherente y organizada, es decir, el destinatario de la misma debe comprender efectivamente lo que se le pregunta para así poder ofrecer la información precisa que se está necesitando de él.
Un cuestionario puede contener diversos tipos de preguntas, entre ellas: abiertas (se aceptan de parte del encuestado cualquier tipo de respuesta, son ricas en detalles, aunque resultan algo incómodas a la hora de la tabulación de las respuestas correspondientes), cerradas (el encuestado responderá en base a una serie restringida de alternativas), semi-abiertas o semi-cerradas (toman elementos de las dos formas anteriores), en batería (se planifican en función de la respuesta dada en una secuencia anterior), de evaluación (dirigidas especialmente para obtener valoraciones del entrevistado), introductorias (figuran al comienzo de la encuesta y tienen únicamente la misión de predisponer favorablemente al encuestado para que acceda a responder el cuestionario completo).
ENTREVISTA
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.
• ESTRUCTURADA:
La entrevista estructurada o preparada es la más estática y rígida de todas, ya que se basa en una serie de preguntas predeterminadas e invariables que deben responder todos los aspirantes a un determinado puesto.
Esto facilita enormemente la unificación de criterios y la valoración del candidato, pero no permite que el entrevistador ahonde en las cuestiones más interesantes. Es recomendable para aquellas empresas que necesitan cubrir muchos puestos de trabajo y no pueden invertir demasiado tiempo en el proceso de selección.
• NO ESTRUCTURADA:
La entrevista no estructurada o libre es aquella en la que se trabaja con preguntas abiertas, sin un orden preestablecido, adquiriendo características de conversación. Esta técnica consiste en realizar preguntas de acuerdo a las respuestas que vayan surgiendo durante la entrevista.
Así, a diferencia de la entrevista estructurada, en este tipo de reunión el entrevistador solo tiene una idea aproximada de lo que se va a preguntar y va improvisando las cuestiones dependiendo del tipo y las características de las respuestas. Además, el énfasis se pone más en el análisis de las impresiones que en el de los hechos.
OBSERVACION:
Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad. Observar no es "mirar". La persona común mira a diario animales, agua, árboles, lluvia, sol, estrellas, vehículo, sin inmutarse por ellos.
La persona con actitud científica percibe esas mismas realidades y procura "observarlas" para tratar por ejemplo, de explicarse el cómo, el por qué de su naturaleza, y para identificar sus elementos constitutivos.
La observación depende en gran medida de los sentidos. Pero, para contrarrestar las limitaciones de nuestros sentidos, el ser humano ha creado instrumentos que lo auxilian para realizar una buena observación. Estos instrumentos aumentan, precisan o reemplazan nuestros sentidos en la observación.
El cuestionario que conforma una encuesta estará compuesto por una cantidad determinada de preguntas, las cuales deberán ser formuladas de forma coherente y organizada, es decir, el destinatario de la misma debe comprender efectivamente lo que se le pregunta para así poder ofrecer la información precisa que se está necesitando de él.
Un cuestionario puede contener diversos tipos de preguntas, entre ellas: abiertas (se aceptan de parte del encuestado cualquier tipo de respuesta, son ricas en detalles, aunque resultan algo incómodas a la hora de la tabulación de las respuestas correspondientes), cerradas (el encuestado responderá en base a una serie restringida de alternativas), semi-abiertas o semi-cerradas (toman elementos de las dos formas anteriores), en batería (se planifican en función de la respuesta dada en una secuencia anterior), de evaluación (dirigidas especialmente para obtener valoraciones del entrevistado), introductorias (figuran al comienzo de la encuesta y tienen únicamente la misión de predisponer favorablemente al encuestado para que acceda a responder el cuestionario completo).
ENTREVISTA
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.
• ESTRUCTURADA:
La entrevista estructurada o preparada es la más estática y rígida de todas, ya que se basa en una serie de preguntas predeterminadas e invariables que deben responder todos los aspirantes a un determinado puesto.
Esto facilita enormemente la unificación de criterios y la valoración del candidato, pero no permite que el entrevistador ahonde en las cuestiones más interesantes. Es recomendable para aquellas empresas que necesitan cubrir muchos puestos de trabajo y no pueden invertir demasiado tiempo en el proceso de selección.
• NO ESTRUCTURADA:
La entrevista no estructurada o libre es aquella en la que se trabaja con preguntas abiertas, sin un orden preestablecido, adquiriendo características de conversación. Esta técnica consiste en realizar preguntas de acuerdo a las respuestas que vayan surgiendo durante la entrevista.
Así, a diferencia de la entrevista estructurada, en este tipo de reunión el entrevistador solo tiene una idea aproximada de lo que se va a preguntar y va improvisando las cuestiones dependiendo del tipo y las características de las respuestas. Además, el énfasis se pone más en el análisis de las impresiones que en el de los hechos.
OBSERVACION:
Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad. Observar no es "mirar". La persona común mira a diario animales, agua, árboles, lluvia, sol, estrellas, vehículo, sin inmutarse por ellos.
La persona con actitud científica percibe esas mismas realidades y procura "observarlas" para tratar por ejemplo, de explicarse el cómo, el por qué de su naturaleza, y para identificar sus elementos constitutivos.
La observación depende en gran medida de los sentidos. Pero, para contrarrestar las limitaciones de nuestros sentidos, el ser humano ha creado instrumentos que lo auxilian para realizar una buena observación. Estos instrumentos aumentan, precisan o reemplazan nuestros sentidos en la observación.
ACTIVIDAD 3 (ANALISIS)
ANALISIS DE SISTEMAS
Un análisis, en sentido amplio, es la descomposición de un todo en partes para poder estudiar su estructura, sistemas operativos, funciones, etc.
Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:
• Identifique las necesidades del Cliente.
• Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad.
• Realice un Análisis Técnico y económico.
• Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.
• Establezca las restricciones de presupuestos y planificación temporal.
• Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.
• Identificación de Necesidades
Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.
• Estudio de Viabilidad
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materialización sin tener perdidas económicas y frustración profesional. La viabilidad y el análisis de riesgos están relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce.
• Análisis Económico y Técnico
El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema.
Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto.
• Diseño de sistemas de computación
El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física.
Un análisis, en sentido amplio, es la descomposición de un todo en partes para poder estudiar su estructura, sistemas operativos, funciones, etc.
Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:
• Identifique las necesidades del Cliente.
• Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad.
• Realice un Análisis Técnico y económico.
• Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.
• Establezca las restricciones de presupuestos y planificación temporal.
• Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.
• Identificación de Necesidades
Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.
• Estudio de Viabilidad
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materialización sin tener perdidas económicas y frustración profesional. La viabilidad y el análisis de riesgos están relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce.
• Análisis Económico y Técnico
El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema.
Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto.
• Diseño de sistemas de computación
El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física.
miércoles, 16 de mayo de 2012
TAREA 1
PARADIGMA ORIENTADO A OBJETOS
Usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento.
Un objeto es una abstracción de algún hecho o ente del mundo real que tiene atributos que representan sus características o propiedades y métodos que representan su comportamiento o acciones que realizan. Todas las propiedades y métodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases.
Las principales propiedades del Paradigma orientada a objetos son:
ABSTRACCION:
Es la propiedad que permite representar las caracteristicas esenciales de un objeto sin preocuparse de las restantes caracteristicas. Se centra en la vista externa de un objeto.
ENCAPSULAMIENTO:
Es la propiedad que permite asegurar que el contenido de un objeto esta oculta al mundo exterior, es decir, el objeto A no conoce lo que hace el objeto B y viceversa.
la encapsulacion permite la division de un programa en modulos, esos modulos se implementan mediante clases, de forma que una clase representa la encapsulacion de una abstraccion.
MODULARIDAD:
Es la propiedad que permite subdividir una aplicacion en partes mas pequeñas llamadas modulos, cada una de las cuales debe ser tan independiente como sea posible de la aplicación en si y de las partes restantes.
JERARQUIA:
Permite una ordenacion de las abstracciones, las dos jerarquias mas importantes de un sistema complejo son:
* Estructuras de clases (especificacion)
* Estructuras de objetos (agregacion)
Usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento.
Un objeto es una abstracción de algún hecho o ente del mundo real que tiene atributos que representan sus características o propiedades y métodos que representan su comportamiento o acciones que realizan. Todas las propiedades y métodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases.
Las principales propiedades del Paradigma orientada a objetos son:
ABSTRACCION:
Es la propiedad que permite representar las caracteristicas esenciales de un objeto sin preocuparse de las restantes caracteristicas. Se centra en la vista externa de un objeto.
ENCAPSULAMIENTO:
Es la propiedad que permite asegurar que el contenido de un objeto esta oculta al mundo exterior, es decir, el objeto A no conoce lo que hace el objeto B y viceversa.
la encapsulacion permite la division de un programa en modulos, esos modulos se implementan mediante clases, de forma que una clase representa la encapsulacion de una abstraccion.
MODULARIDAD:
Es la propiedad que permite subdividir una aplicacion en partes mas pequeñas llamadas modulos, cada una de las cuales debe ser tan independiente como sea posible de la aplicación en si y de las partes restantes.
JERARQUIA:
Permite una ordenacion de las abstracciones, las dos jerarquias mas importantes de un sistema complejo son:
* Estructuras de clases (especificacion)
* Estructuras de objetos (agregacion)
jueves, 10 de mayo de 2012
ACTIVIDAD 2 "PARADIGMAS"
PARADIGMAS
PARADIGMA CICLO DE VIDA DEL SOFTWARE:
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS:
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir.
CARACTERISTICAS:
• Este paradigma ayuda al cliente a brindar requisitos paso a paso.
• También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
• Consiste en la creación de prototipos
DESVENTAJAS:
La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:
1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software. Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.
2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.
PARADIGMA DEL MODELO ESPIRAL:
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS:
• Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.
• Incluye la etapa de análisis de riesgos, no incluida anteriormente.
• Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras.
• La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
• Este es el enfoque más realista actualmente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.
PROBLEMAS:
• Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.
• Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolución
EL MODELO DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.
PARADIGMA DE TÉCNICAS DE CUARTA GENERACION
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Para resumir las técnicas de cuarta generación se convertirán en una parte importante en el desarrollo del software durante la siguiente década. Como muestra la siguiente figura la demanda del software continuara creciendo durante el resto del siglo, pero los métodos y paradigmas convencionales contribuirán cada vez menos al desarrollo del mismo.
EL MODELO DE DESARROLLO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
COMBINACIÓN DE PARADIGMAS
Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.
En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.
La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.
PARADIGMA CICLO DE VIDA DEL SOFTWARE:
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS:
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir.
CARACTERISTICAS:
• Este paradigma ayuda al cliente a brindar requisitos paso a paso.
• También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
• Consiste en la creación de prototipos
DESVENTAJAS:
La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:
1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software. Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.
2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.
PARADIGMA DEL MODELO ESPIRAL:
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS:
• Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.
• Incluye la etapa de análisis de riesgos, no incluida anteriormente.
• Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras.
• La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
• Este es el enfoque más realista actualmente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.
PROBLEMAS:
• Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.
• Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolución
EL MODELO DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.
PARADIGMA DE TÉCNICAS DE CUARTA GENERACION
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Para resumir las técnicas de cuarta generación se convertirán en una parte importante en el desarrollo del software durante la siguiente década. Como muestra la siguiente figura la demanda del software continuara creciendo durante el resto del siglo, pero los métodos y paradigmas convencionales contribuirán cada vez menos al desarrollo del mismo.
EL MODELO DE DESARROLLO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
COMBINACIÓN DE PARADIGMAS
Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.
En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.
La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.
martes, 8 de mayo de 2012
AUTOEVALUACION
¿QUE ES LA INGENIERIA DE SOFTWARE?
Es la ciencia que ayuda a elaborar sistemas con el fin de que sea economico
¿PARA QUE SON LOS METODOS DE LA INGENIERIA DE SOFTWARE?
Suministran como construir tecnicamente el software
¿QUE SON LOS PROCEDIMIENTOS?
Es el pegamento que amalgama a los metodos y herramientas
¿QUE SON LAS HERRAMIENTAS?
Son los metodos necesarios para desarrollar el sistema
¿PARA QUE NOS SIRVEN LAS HERRAMIENTAS?
Suministran un soporte automatico o semiautomatico para los metodos
Es la ciencia que ayuda a elaborar sistemas con el fin de que sea economico
¿PARA QUE SON LOS METODOS DE LA INGENIERIA DE SOFTWARE?
Suministran como construir tecnicamente el software
¿QUE SON LOS PROCEDIMIENTOS?
Es el pegamento que amalgama a los metodos y herramientas
¿QUE SON LAS HERRAMIENTAS?
Son los metodos necesarios para desarrollar el sistema
¿PARA QUE NOS SIRVEN LAS HERRAMIENTAS?
Suministran un soporte automatico o semiautomatico para los metodos
ACTIVIDAD 1
INGENIERIA DE SOFTWARE:
1.- Es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan en el desarrollo de los programas informáticos
(software).
Esta disciplina trasciende la actividad de programación, que es la
actividad principal a la hora de crear un software. El ingeniero de
software se encarga de toda la gestión del proyecto para que éste se pueda
desarrollar en un plazo determinado y con el presupuesto previsto.
2.- El término ingeniería de software abarca al grupo de métodos, técnicas y
herramientas que se utilizan en la producción del software, más allá de
la actividad principal de programación.
El término "ingeniería" es una referencia directa a la ingeniería civil,
una referencia al estudio de la construcción. En programación se aplica
el mismo principio que en la construcción de un edificio: poner
simplemente ladrillos y cemento no es suficiente. La construcción de un
edificio consta de diversos pasos antes de comenzar con la fase de
construcción, tales como el diseño arquitectónico, la albañilería, la
fontanería, el diseño eléctrico, y durante este período se calculan los
presupuestos y los plazos.
Por lo tanto, la ingeniería de software requiere la gestión de proyectos
para que se pueda desarrollar una aplicación en el plazo previsto y con
el presupuesto establecido que sea satisfactoria para el cliente (el
concepto de calidad).
3 ELEMENTOS CLAVE:
ECONOMICO: Debe ser un sistema que pueda ser pagado de acuerdo a sus caracteristicas.
FIABLE: Se dice que la fiabilidad de un sistema es la probabilidad de que ese sistema funcione o desarrolle una cierta función, bajo condiciones fijadas y durante un período determinado.
FUNCIONALIDAD EFICIENTE: Se refiere a que el sistema debe trabajar y hacerlo bien con los mejores metodos posibles, y de acuerdo a las caracteristicas del sistema en el que funciona.
CICLO DE VIDA DE SISTEMAS:
El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.
Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.
*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.
*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.
*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.
1.- Es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan en el desarrollo de los programas informáticos
(software).
Esta disciplina trasciende la actividad de programación, que es la
actividad principal a la hora de crear un software. El ingeniero de
software se encarga de toda la gestión del proyecto para que éste se pueda
desarrollar en un plazo determinado y con el presupuesto previsto.
2.- El término ingeniería de software abarca al grupo de métodos, técnicas y
herramientas que se utilizan en la producción del software, más allá de
la actividad principal de programación.
El término "ingeniería" es una referencia directa a la ingeniería civil,
una referencia al estudio de la construcción. En programación se aplica
el mismo principio que en la construcción de un edificio: poner
simplemente ladrillos y cemento no es suficiente. La construcción de un
edificio consta de diversos pasos antes de comenzar con la fase de
construcción, tales como el diseño arquitectónico, la albañilería, la
fontanería, el diseño eléctrico, y durante este período se calculan los
presupuestos y los plazos.
Por lo tanto, la ingeniería de software requiere la gestión de proyectos
para que se pueda desarrollar una aplicación en el plazo previsto y con
el presupuesto establecido que sea satisfactoria para el cliente (el
concepto de calidad).
3 ELEMENTOS CLAVE:
ECONOMICO: Debe ser un sistema que pueda ser pagado de acuerdo a sus caracteristicas.
FIABLE: Se dice que la fiabilidad de un sistema es la probabilidad de que ese sistema funcione o desarrolle una cierta función, bajo condiciones fijadas y durante un período determinado.
FUNCIONALIDAD EFICIENTE: Se refiere a que el sistema debe trabajar y hacerlo bien con los mejores metodos posibles, y de acuerdo a las caracteristicas del sistema en el que funciona.
CICLO DE VIDA DE SISTEMAS:
El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.
Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.
*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.
*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.
*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.
Suscribirse a:
Comentarios (Atom)