miércoles, 2 de diciembre de 2009
ESTROBE
Al observar al tomador de decisiones, el analista intenta ver de primera mano las relaciones que existen entre estos y los demás miembros de la organización. El analista examina los elementos físicos del espacio de trabajo del tomador para ver su influencia sobre el comportamiento del mismo. La observación también permite que el analista vea de primera mano como los gerentes recopilan, procesan, comparten y usan la información para hacer que el trabajo se realice.
Frecuentemente es posible observar particularidades acerca del ambiente que confirman o niegan la narración organizacional que se encuentra por medio de entrevistas o cuestionarios.
El método para la observación estructurada del ambiente es llamado STROBE. Es sistemático debido a que proporciona una metodología estándar y una clasificación estándar para el análisis de los elementos organizacionales que influencian la toma la toma de decisiones y permite que otros analistas de sistemas apliquen el mismo marco de trabajo analítico a la misma organización.
Elementos ESTROBE
Hay 7 elementos concretos que son fácilmente observables por el analista de sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo. Estos son los 7 elementos:
1. Ubicación de la oficina: El analista de sistemas debe observar la ubicación de la oficina de un tomador de decisiones particular, con respecto a las demás oficinas. Las oficinas accesibles tienden a incrementar la frecuencia de interacción y los mensajes informales y, en cambio, las oficinas inaccesibles tienden a disminuir la frecuencia de interacción e incrementar los mensajes orientados a tarea. También es probable que las personas cuyas oficinas están separadas de otras puedan tender a ver la organización en forma diferente y, por lo tanto, se desvíen mucho más de los demás miembros de la organización en sus objetivos.
2. La ubicación de un escritorio en la oficina: puede proporcionar pistas sobre el ejercicio de poder por el tomador de decisiones. Los ejecutivos que encierran al visitante en un espacio estrecho con su espalda hacia la pared y que a su vez se permiten una gran cantidad de espacio para ellos mismos, se ponen a si mismos en la posición de poder mas fuerte posible. Un ejecutivo que da posición a su escritorio viendo hacia la pared con una silla a un lado para un visitante, probablemente esta favoreciendo la participación a nivel de igualdad.
3. Equipo de oficina fijo: Los archiveros, libreros y otros muebles grandes para el almacenamiento de cosas quedan incluidos en la categoría de hombre. Mediante el uso de ESTROBE el analista de sistemas puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información.
4. Propiedades: Hace referencia a todo el equipo pequeño que se usa para procesar información.
5. Revistas y periódicos del negocio: Un analista de sistemas necesita saber que tipo de información es usada por el tomador de decisiones. La observación del tipo de publicaciones almacenadas en la oficina puede revelar si el tomador de decisiones busca información externa o se apoya más en información interna.
6. Iluminación y color en la oficina: Juegan un papel importante en la manera en que un tomador de decisiones recopila información. Una oficina alumbrada con iluminación incandescente calida indica una tendencia hacia comunicación mas personal. Un ejecutivo en una oficina iluminada calidamente recopilara mas información informalmente y, en cambio, otro miembro de la organización que trabaje en una oficina brillantemente iluminada y coloreada puede recolectar información mediante memorandums más formales y reportes oficiales.
7. Vestimenta usada por los tomadores de decisiones: El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes en la organización observando la vestimenta que usan en el trabajo. El traje formal de 3 piezas para un hombre, o el traje sastre para una mujer, representa la máxima autoridad. La vestimenta casual por parte de los líderes tiende a abrir la puerta para una toma de decisiones mas participativa, pero frecuentemente da como resultado alguna perdida de credibilidad en la organización.
ALTERNATIVAS DE APLICACIÓN: Los analistas pueden escoger entre muchas estrategias de aplicación cuando usan el enfoque ESTROBE. Estas estrategias varían desde muy estructuradas (como tomar fotografías), hasta sin estructura. Estas son las 4 estrategias:
1. Análisis de fotografías: Las aplicaciones fotográficas de ESTROBE tienen algunas ventajas distintivas. Una es que pueden hacer un documento al que se puede hacer referencia repetidamente. Esto puede ser extremadamente útil cuando las visitas a la organización deben ser limitadas debido a tiempo, distancia y gastos. El uso de la fotografía para ESTROBE permite una comparación lado a lado de las organizaciones, debido a que las limitaciones de tiempo y espacio son superadas por la fotografía. Otra ventaja es que la fotografía puede proporcionar detalles que fácilmente se descuidan durante el contacto personal.
2. Enfoque de la lista de verificación/escala Likert: Una segunda aplicación de ESTROBE es una técnica menos estructurada que la fotografía, un enfoque de lista de verificación/escala Likert. Los investigadores desarrollaron escalas tipo Likert de cinco puntos en relación con 7 características del tomador de decisiones que fueron observables por medio de elementos físicos en los ambientes organizacionales de los tomadores de decisiones.
3. Listas anecdóticas (con símbolos): La tercera y hasta menos estructurada forma de implementar ESTROBE es por medio del uso de una lista de verificación anecdótica con símbolos de abreviaturas significativos. Cuando ESTROBE es implementado de esta manera, el primer paso es determinar los temas organizacionales principales que se desprender de las entrevistas. Luego son observados sistemáticamente los elementos de ESTROBE, y luego se construye una matriz, que lista las ideas principales a partir de la narrativa organizacional acerca de la recopilación, procesamiento, almacenamiento y comparación de la información en un eje y los elementos de ESTROBE en el otro.
4. Comparación de la observación/narrativa: La cuarta forma de implementar ESTROBE es también el método menos estructurado. Mientras el analista de sistemas este conciente de los elementos del mise-en-scene y estos sena observados concienzudamente, se pueden obtener apreciaciones valiosas, incluso sin la ayuda de la lista de verificación.
Frecuentemente es posible observar particularidades acerca del ambiente que confirman o niegan la narración organizacional que se encuentra por medio de entrevistas o cuestionarios.
El método para la observación estructurada del ambiente es llamado STROBE. Es sistemático debido a que proporciona una metodología estándar y una clasificación estándar para el análisis de los elementos organizacionales que influencian la toma la toma de decisiones y permite que otros analistas de sistemas apliquen el mismo marco de trabajo analítico a la misma organización.
Elementos ESTROBE
Hay 7 elementos concretos que son fácilmente observables por el analista de sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo. Estos son los 7 elementos:
1. Ubicación de la oficina: El analista de sistemas debe observar la ubicación de la oficina de un tomador de decisiones particular, con respecto a las demás oficinas. Las oficinas accesibles tienden a incrementar la frecuencia de interacción y los mensajes informales y, en cambio, las oficinas inaccesibles tienden a disminuir la frecuencia de interacción e incrementar los mensajes orientados a tarea. También es probable que las personas cuyas oficinas están separadas de otras puedan tender a ver la organización en forma diferente y, por lo tanto, se desvíen mucho más de los demás miembros de la organización en sus objetivos.
2. La ubicación de un escritorio en la oficina: puede proporcionar pistas sobre el ejercicio de poder por el tomador de decisiones. Los ejecutivos que encierran al visitante en un espacio estrecho con su espalda hacia la pared y que a su vez se permiten una gran cantidad de espacio para ellos mismos, se ponen a si mismos en la posición de poder mas fuerte posible. Un ejecutivo que da posición a su escritorio viendo hacia la pared con una silla a un lado para un visitante, probablemente esta favoreciendo la participación a nivel de igualdad.
3. Equipo de oficina fijo: Los archiveros, libreros y otros muebles grandes para el almacenamiento de cosas quedan incluidos en la categoría de hombre. Mediante el uso de ESTROBE el analista de sistemas puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información.
4. Propiedades: Hace referencia a todo el equipo pequeño que se usa para procesar información.
5. Revistas y periódicos del negocio: Un analista de sistemas necesita saber que tipo de información es usada por el tomador de decisiones. La observación del tipo de publicaciones almacenadas en la oficina puede revelar si el tomador de decisiones busca información externa o se apoya más en información interna.
6. Iluminación y color en la oficina: Juegan un papel importante en la manera en que un tomador de decisiones recopila información. Una oficina alumbrada con iluminación incandescente calida indica una tendencia hacia comunicación mas personal. Un ejecutivo en una oficina iluminada calidamente recopilara mas información informalmente y, en cambio, otro miembro de la organización que trabaje en una oficina brillantemente iluminada y coloreada puede recolectar información mediante memorandums más formales y reportes oficiales.
7. Vestimenta usada por los tomadores de decisiones: El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes en la organización observando la vestimenta que usan en el trabajo. El traje formal de 3 piezas para un hombre, o el traje sastre para una mujer, representa la máxima autoridad. La vestimenta casual por parte de los líderes tiende a abrir la puerta para una toma de decisiones mas participativa, pero frecuentemente da como resultado alguna perdida de credibilidad en la organización.
ALTERNATIVAS DE APLICACIÓN: Los analistas pueden escoger entre muchas estrategias de aplicación cuando usan el enfoque ESTROBE. Estas estrategias varían desde muy estructuradas (como tomar fotografías), hasta sin estructura. Estas son las 4 estrategias:
1. Análisis de fotografías: Las aplicaciones fotográficas de ESTROBE tienen algunas ventajas distintivas. Una es que pueden hacer un documento al que se puede hacer referencia repetidamente. Esto puede ser extremadamente útil cuando las visitas a la organización deben ser limitadas debido a tiempo, distancia y gastos. El uso de la fotografía para ESTROBE permite una comparación lado a lado de las organizaciones, debido a que las limitaciones de tiempo y espacio son superadas por la fotografía. Otra ventaja es que la fotografía puede proporcionar detalles que fácilmente se descuidan durante el contacto personal.
2. Enfoque de la lista de verificación/escala Likert: Una segunda aplicación de ESTROBE es una técnica menos estructurada que la fotografía, un enfoque de lista de verificación/escala Likert. Los investigadores desarrollaron escalas tipo Likert de cinco puntos en relación con 7 características del tomador de decisiones que fueron observables por medio de elementos físicos en los ambientes organizacionales de los tomadores de decisiones.
3. Listas anecdóticas (con símbolos): La tercera y hasta menos estructurada forma de implementar ESTROBE es por medio del uso de una lista de verificación anecdótica con símbolos de abreviaturas significativos. Cuando ESTROBE es implementado de esta manera, el primer paso es determinar los temas organizacionales principales que se desprender de las entrevistas. Luego son observados sistemáticamente los elementos de ESTROBE, y luego se construye una matriz, que lista las ideas principales a partir de la narrativa organizacional acerca de la recopilación, procesamiento, almacenamiento y comparación de la información en un eje y los elementos de ESTROBE en el otro.
4. Comparación de la observación/narrativa: La cuarta forma de implementar ESTROBE es también el método menos estructurado. Mientras el analista de sistemas este conciente de los elementos del mise-en-scene y estos sena observados concienzudamente, se pueden obtener apreciaciones valiosas, incluso sin la ayuda de la lista de verificación.
ANALISIS Y RECOPILACION DE DOCUMENTOS
El analista de sistemas busca hechos y cifras, es decir, datos relevantes. Es muy importante que el analista pregunte por quien fueron producidos originalmente los documentos y porque han sido conservados, es decir, que se necesita comprender el papel del documento en las necesidades de la organización.
Tipos de datos impresos
El analista necesita examinar los datos impresos, tanto cuantitativa como cualitativamente, para ensamblar una imagen precisa.
Análisis de documentos cuantitativos: Se dispone de una variedad de documentos cuantitativos para su interpretación en cualquier negocio. Estos incluyen reportes usados para la toma de decisiones, reportes de desempeño y diversas formas. Todos estos documentos tienen un objetivo específico y una audiencia hacia la que están dirigidos.
• Reportes usados para la toma de decisiones: Un analista de sistemas necesita obtener algunos de los documentos que son usados para el desempeño del negocio. Estos documentos son frecuentemente reportes en papel con relación al estado del inventario, las ventas o la producción, estos sirven como retroalimentación para una acción rápida.
• Reportes de desempeño: Toman la forma general de desempeño actual contra el programado. Una función importante de los reportes de desempeño es valorar el tamaño de la diferencia entre el desempeño actual y el pretendido.
• Registros: Los registros proporcionan actualizaciones periódicas de lo que esta sucediendo en el negocio. Si el registro es actualizado en forma periódica por un registrador cuidadoso, puede proporcionar mucha información al analista.
• Formas para capturar datos: Las formas en blanco, junto con sus instrucciones para ser llenadas y distribuidas, pueden ser comparadas con las formas que han sido llenadas para ver si cualquier concepto de datos es permanente dejado en blanco en las formas, si las personas que se supone deben recibir las formas, de hecho las obtienen, y si siguen procedimientos estándares para el uso, almacenamiento y eliminación de ellas.
Análisis de documentos cualitativos: Aunque los documentos cualitativos tal vez no sigan una forma predeterminada, el análisis de ellos es critico para la comprensión de la manera en que los miembros de la organización engranan en el proceso de la organización. Los documentos cualitativos incluyen memorandums, consignas en tableros de noticias y en áreas de trabajo, manuales de procedimientos y manuales de política.
• Memorandums: Siempre que sea posible, el analista debe muestrear los memorandums que se envían en el interior del negocio. El analista debe considerar quien envía los memorandums y quien los recibe. Los memorandums revelan un dialogo vivo y continuo en la organización. El análisis del contenido de los memorandums proporcionara una idea clara de los valores, actitudes y creencias de los miembros de la organización.
• Consignas en un tablero de noticias o en áreas de trabajo: Aunque loas consignas pueden parecer incidentales a lo que esta sucediendo en la organización, sirven como reforzadores sutiles de los valores de quienes los leen. También es instructivo notar hacia quien están dirigidas las consignas y encontrar por medio de entrevistas si los miembros de la organización son responsables para actuar sobre la información mostrada.
• Manuales: Otros documentos cualitativos que el analista debe examinar son los manuales organizacionales, incluyendo los manuales para los procedimientos de operación de computadora. Debemos recordar que los manuales son el “ideal”, la forma en que se espera que se comporten las maquinas y personas. La examinación sistemática de manuales le dará una imagen de la forma en que las cosas debieran pasar.
• Manuales de política: Estos documentos cubren típicamente áreas amplias del comportamiento de los empleados y la compañía, se pude estar relacionado primariamente con aquellos que establecen políticas acerca de servicios, uso, acceso y cambios relativos a computación. Las políticas son grandes lineamientos que hablan sobre la manera en que deben comportarse los miembros por si mismos para lograr objetivos estratégicos.
El analista de sistemas también puede tomar decisiones con base en un enfoque estructural llamado muestreo.
Muestreo: Es el proceso de seleccionar sistemáticamente elementos representativos de una población. Cuando estos elementos seleccionados son examinados de cerca, se supone que el análisis revelará información útil acerca de la población como un todo.
Hay muchas razones por las que un analista de sistemas quiera seleccionar una muestra representativa de los datos a examinar, o personas representativas a entrevistar, aplicar cuestionarios u observar. Estas son algunas de ellas:
• Los costos contenidos
• La agilización de la recolección de datos
• La mejora de la efectividad
• La reducción de la ascendencia
El muestreo ayuda a acelerar el proceso, recolectando datos seleccionados en vez de todos los datos de la población completa. El muestreo puede ayudar a mejorar la efectividad que si se obtuviera información mas precisa.
Diseño del muestreo: Los cuatro pasos que debe seguir un analista de sistemas para diseñar una buena muestra son:
1. Determinar los datos a ser recolectados o descritos
2. Determinar la población a ser muestreada
3. Seleccionar el tipo de muestra
4. Decidir el tamaño de muestra
Tipos de datos impresos
El analista necesita examinar los datos impresos, tanto cuantitativa como cualitativamente, para ensamblar una imagen precisa.
Análisis de documentos cuantitativos: Se dispone de una variedad de documentos cuantitativos para su interpretación en cualquier negocio. Estos incluyen reportes usados para la toma de decisiones, reportes de desempeño y diversas formas. Todos estos documentos tienen un objetivo específico y una audiencia hacia la que están dirigidos.
• Reportes usados para la toma de decisiones: Un analista de sistemas necesita obtener algunos de los documentos que son usados para el desempeño del negocio. Estos documentos son frecuentemente reportes en papel con relación al estado del inventario, las ventas o la producción, estos sirven como retroalimentación para una acción rápida.
• Reportes de desempeño: Toman la forma general de desempeño actual contra el programado. Una función importante de los reportes de desempeño es valorar el tamaño de la diferencia entre el desempeño actual y el pretendido.
• Registros: Los registros proporcionan actualizaciones periódicas de lo que esta sucediendo en el negocio. Si el registro es actualizado en forma periódica por un registrador cuidadoso, puede proporcionar mucha información al analista.
• Formas para capturar datos: Las formas en blanco, junto con sus instrucciones para ser llenadas y distribuidas, pueden ser comparadas con las formas que han sido llenadas para ver si cualquier concepto de datos es permanente dejado en blanco en las formas, si las personas que se supone deben recibir las formas, de hecho las obtienen, y si siguen procedimientos estándares para el uso, almacenamiento y eliminación de ellas.
Análisis de documentos cualitativos: Aunque los documentos cualitativos tal vez no sigan una forma predeterminada, el análisis de ellos es critico para la comprensión de la manera en que los miembros de la organización engranan en el proceso de la organización. Los documentos cualitativos incluyen memorandums, consignas en tableros de noticias y en áreas de trabajo, manuales de procedimientos y manuales de política.
• Memorandums: Siempre que sea posible, el analista debe muestrear los memorandums que se envían en el interior del negocio. El analista debe considerar quien envía los memorandums y quien los recibe. Los memorandums revelan un dialogo vivo y continuo en la organización. El análisis del contenido de los memorandums proporcionara una idea clara de los valores, actitudes y creencias de los miembros de la organización.
• Consignas en un tablero de noticias o en áreas de trabajo: Aunque loas consignas pueden parecer incidentales a lo que esta sucediendo en la organización, sirven como reforzadores sutiles de los valores de quienes los leen. También es instructivo notar hacia quien están dirigidas las consignas y encontrar por medio de entrevistas si los miembros de la organización son responsables para actuar sobre la información mostrada.
• Manuales: Otros documentos cualitativos que el analista debe examinar son los manuales organizacionales, incluyendo los manuales para los procedimientos de operación de computadora. Debemos recordar que los manuales son el “ideal”, la forma en que se espera que se comporten las maquinas y personas. La examinación sistemática de manuales le dará una imagen de la forma en que las cosas debieran pasar.
• Manuales de política: Estos documentos cubren típicamente áreas amplias del comportamiento de los empleados y la compañía, se pude estar relacionado primariamente con aquellos que establecen políticas acerca de servicios, uso, acceso y cambios relativos a computación. Las políticas son grandes lineamientos que hablan sobre la manera en que deben comportarse los miembros por si mismos para lograr objetivos estratégicos.
El analista de sistemas también puede tomar decisiones con base en un enfoque estructural llamado muestreo.
Muestreo: Es el proceso de seleccionar sistemáticamente elementos representativos de una población. Cuando estos elementos seleccionados son examinados de cerca, se supone que el análisis revelará información útil acerca de la población como un todo.
Hay muchas razones por las que un analista de sistemas quiera seleccionar una muestra representativa de los datos a examinar, o personas representativas a entrevistar, aplicar cuestionarios u observar. Estas son algunas de ellas:
• Los costos contenidos
• La agilización de la recolección de datos
• La mejora de la efectividad
• La reducción de la ascendencia
El muestreo ayuda a acelerar el proceso, recolectando datos seleccionados en vez de todos los datos de la población completa. El muestreo puede ayudar a mejorar la efectividad que si se obtuviera información mas precisa.
Diseño del muestreo: Los cuatro pasos que debe seguir un analista de sistemas para diseñar una buena muestra son:
1. Determinar los datos a ser recolectados o descritos
2. Determinar la población a ser muestreada
3. Seleccionar el tipo de muestra
4. Decidir el tamaño de muestra
El cuestionario
El cuestionario
El cuestionario es una técnica de recolección de datos y está conformado por un conjunto de
preguntas escritas que el investigador administra o aplica a las personas o unidades de análisis, a fin de obtener la información empírica necesaria para determinar los valores o respuestas de las variables es motivo de estudio. No es muy confiable, ya que las respuestas obtenidas no pueden ser fácilmente verificadas o pueden estar "elaboradas por motivos propios o de grupo".
El cuestionario, tanto para su elaboración como aplicación, debe considerar las siguientes fases:
Determinación de los objetivos del cuestionario, que están referidos a obtener información para analizar el problema motivo de la investigación.
Identificación de los variables a investigar, que orientan el tipo e información que debe ser recolectado.
Delimitación del universo o población bajo estudio, donde será aplicado el cuestionario; las
Selección del tipo de cuestionario y forma de administración.
Elaboración del cuestionario como instrumento de recolección de datos.
El pre-test o prueba piloto.
Aplicación del cuestionario o trabajo de campo para la recolección de los datos.
Crítica y codificación de la información recolectada.
Plan de procesamiento y análisis estadística de la información recolectada.
partes del cuestionario
Título que específica a quien va dirigido el cuestionario.
Introducción o presentación; resume los objetivos del cuestionario, la población bajo estudio, la institución que lleva a cabo la investigación y el carácter anónimo y científico de la información requerida para motivar la colaboración del informante.
Identificación del cuestionario; específica un número para cada cuestionario aplicado, lugar y fecha de aplicación, dirección y teléfono del informante.
.
Una última parte, donde se debe especificar el nombre, la dirección y el teléfono del que aplicó el
cuestionario (cuando no es auto-administrado); así como las observaciones que este desee hacer.
En algunos estudios, en esta parte del cuestionario, también se incluyen preguntas que deben ser
respondidas por el entrevistador, cuando no ha sido posible ubicar al informante. Estas preguntas,
incluso, pueden ser respondidas con la colaboración de terceras personas.
Tipos de preguntas
Las preguntas constituyen el cuerpo del cuestionario y pueden ser de dos tipos:
• La pregunta cerrada o estructurada; es la que conlleva alternativas de respuesta que son
presentadas al informante para su elección. Este tipo de pregunta tiene el riesgo de no captar toda
la información que el entrevistado pueda dar, sobre todo si las alternativas de respuesta no se
adecua al del informante. De allí que la lista de alternativas de respuesta debe incluir la categoría
“otra respuesta”, incluyendo la advertencia de describir ese otro tipo de respuesta, a fin de que
constituya una fuente de información para su análisis.
La principal ventaja de este tipo de pregunta es que facilita su procesamiento y análisis estadístico.
• La pregunta abierta o no estructurada; es la que deja en plena libertad al informante en la
elaboración de su respuesta, sin ningún tipo de limitaciones, únicamente se tiene como referencia
el marco de la información que requiere la interrogante. La principal ventaja, es que permite
obtener una información detallada y, la principal desventaja, es que dificulta su procesamiento
estadístico, siendo necesaria la utilización de otra técnica auxiliar como es el análisis de contenido.
Estas preguntas generalmente se formulan cuando los indicadores son difíciles de categorizar por
el elevado grado de complejidad del aspecto de la realidad que se investiga.
Tipos de cuestionario
• Cuestionarios con preguntas cerradas.
• Cuestionarios con preguntas abiertos.
• Cuestionario mixtos, que combinan preguntas cerradas con preguntas abiertas. Este tipo de
cuestionario es el más usual en la investigación social para la recolección de datos.
Ventajas del cuestionario
Es menos costoso que la entrevista; por cuanto en muchos casos no es imprescindible la
presencia de una personas en la aplicación del cuestionario (cuestionario auto administrado)
La aplicación del cuestionario no necesita de un personal especializado en el tema de la
investigación, como si es imprescindible en el caso de la entrevista.
Es más uniforme en los datos que se recolecta, pues las preguntas son las mismas para todos los
informantes.
El cuestionario, a diferencia de la entrevista, es más funcional en su aplicación a muestras
grandes, incluso por más dispersos que los informantes estén geográficamente; pues, como se ha
señalado anteriormente, el cuestionario puede ser enviado por correo.
Si el cuestionario es enviado por correo, el informante puede sentirse más seguro del anonimato
de sus respuestas y dar una mayor información confiable.
Es menos costosa la sistematización y procesamiento estadístico de la información, que en el caso
de la entrevista.
Desventajas del cuestionario
Es demasiado rígido y en consecuencia permite la recolección únicamente del dato al que se
refiere la pregunta.
Esto puede dar lugar a una pérdida de información importante para el análisis del problema motivo
de investigación.
Es demasiado formal y puede ocasionar resistencia en el informante a contestar determinadas
preguntas.
En la medida que las preguntas deben ser hechas a todos los informantes, tal como están escritas,
hay mayor posibilidad, que en la entrevista, de obtener demasiadas “no respuestas” o respuestas
erróneas; sobre todo cuando el informante no comprende el correcto sentido de la pregunta.
En conclusión, en la investigación social, lo más apropiado para la recolección de datos es
combinar el uso de la técnica del cuestionario con la técnica de la entrevista.
El cuestionario es una técnica de recolección de datos y está conformado por un conjunto de
preguntas escritas que el investigador administra o aplica a las personas o unidades de análisis, a fin de obtener la información empírica necesaria para determinar los valores o respuestas de las variables es motivo de estudio. No es muy confiable, ya que las respuestas obtenidas no pueden ser fácilmente verificadas o pueden estar "elaboradas por motivos propios o de grupo".
El cuestionario, tanto para su elaboración como aplicación, debe considerar las siguientes fases:
Determinación de los objetivos del cuestionario, que están referidos a obtener información para analizar el problema motivo de la investigación.
Identificación de los variables a investigar, que orientan el tipo e información que debe ser recolectado.
Delimitación del universo o población bajo estudio, donde será aplicado el cuestionario; las
Selección del tipo de cuestionario y forma de administración.
Elaboración del cuestionario como instrumento de recolección de datos.
El pre-test o prueba piloto.
Aplicación del cuestionario o trabajo de campo para la recolección de los datos.
Crítica y codificación de la información recolectada.
Plan de procesamiento y análisis estadística de la información recolectada.
partes del cuestionario
Título que específica a quien va dirigido el cuestionario.
Introducción o presentación; resume los objetivos del cuestionario, la población bajo estudio, la institución que lleva a cabo la investigación y el carácter anónimo y científico de la información requerida para motivar la colaboración del informante.
Identificación del cuestionario; específica un número para cada cuestionario aplicado, lugar y fecha de aplicación, dirección y teléfono del informante.
.
Una última parte, donde se debe especificar el nombre, la dirección y el teléfono del que aplicó el
cuestionario (cuando no es auto-administrado); así como las observaciones que este desee hacer.
En algunos estudios, en esta parte del cuestionario, también se incluyen preguntas que deben ser
respondidas por el entrevistador, cuando no ha sido posible ubicar al informante. Estas preguntas,
incluso, pueden ser respondidas con la colaboración de terceras personas.
Tipos de preguntas
Las preguntas constituyen el cuerpo del cuestionario y pueden ser de dos tipos:
• La pregunta cerrada o estructurada; es la que conlleva alternativas de respuesta que son
presentadas al informante para su elección. Este tipo de pregunta tiene el riesgo de no captar toda
la información que el entrevistado pueda dar, sobre todo si las alternativas de respuesta no se
adecua al del informante. De allí que la lista de alternativas de respuesta debe incluir la categoría
“otra respuesta”, incluyendo la advertencia de describir ese otro tipo de respuesta, a fin de que
constituya una fuente de información para su análisis.
La principal ventaja de este tipo de pregunta es que facilita su procesamiento y análisis estadístico.
• La pregunta abierta o no estructurada; es la que deja en plena libertad al informante en la
elaboración de su respuesta, sin ningún tipo de limitaciones, únicamente se tiene como referencia
el marco de la información que requiere la interrogante. La principal ventaja, es que permite
obtener una información detallada y, la principal desventaja, es que dificulta su procesamiento
estadístico, siendo necesaria la utilización de otra técnica auxiliar como es el análisis de contenido.
Estas preguntas generalmente se formulan cuando los indicadores son difíciles de categorizar por
el elevado grado de complejidad del aspecto de la realidad que se investiga.
Tipos de cuestionario
• Cuestionarios con preguntas cerradas.
• Cuestionarios con preguntas abiertos.
• Cuestionario mixtos, que combinan preguntas cerradas con preguntas abiertas. Este tipo de
cuestionario es el más usual en la investigación social para la recolección de datos.
Ventajas del cuestionario
Es menos costoso que la entrevista; por cuanto en muchos casos no es imprescindible la
presencia de una personas en la aplicación del cuestionario (cuestionario auto administrado)
La aplicación del cuestionario no necesita de un personal especializado en el tema de la
investigación, como si es imprescindible en el caso de la entrevista.
Es más uniforme en los datos que se recolecta, pues las preguntas son las mismas para todos los
informantes.
El cuestionario, a diferencia de la entrevista, es más funcional en su aplicación a muestras
grandes, incluso por más dispersos que los informantes estén geográficamente; pues, como se ha
señalado anteriormente, el cuestionario puede ser enviado por correo.
Si el cuestionario es enviado por correo, el informante puede sentirse más seguro del anonimato
de sus respuestas y dar una mayor información confiable.
Es menos costosa la sistematización y procesamiento estadístico de la información, que en el caso
de la entrevista.
Desventajas del cuestionario
Es demasiado rígido y en consecuencia permite la recolección únicamente del dato al que se
refiere la pregunta.
Esto puede dar lugar a una pérdida de información importante para el análisis del problema motivo
de investigación.
Es demasiado formal y puede ocasionar resistencia en el informante a contestar determinadas
preguntas.
En la medida que las preguntas deben ser hechas a todos los informantes, tal como están escritas,
hay mayor posibilidad, que en la entrevista, de obtener demasiadas “no respuestas” o respuestas
erróneas; sobre todo cuando el informante no comprende el correcto sentido de la pregunta.
En conclusión, en la investigación social, lo más apropiado para la recolección de datos es
combinar el uso de la técnica del cuestionario con la técnica de la entrevista.
La entrevista
La entrevista
Es una técnica para recopilar información a partir de un intercambio directo entre personas o grupos. Es uno de los métodos mas populares. El objetivo de una entrevista es buscar hechos (realidad objetiva) los cuales los tiene otra persona.Su fase de recolección de datos se obtiene mediante un conjunto de preguntas, orales o escritos, que se les hace a las personas involucradas en el problema motivo de estudio.
EL ENTREVISTADO debe ser siempre una persona que interese a la comunidad. El entrevistado es la persona que tiene alguna idea o alguna experiencia importante que transmitir.
EL ENTREVISTADOR es el que dirige la entrevista debe dominar el dialogo, presenta al entrevistado y el tema principal, hace preguntas adecuadas y cierra la entrevista.
PARTES DE UNA ENTREVISTA.
@ La presentación debe ser breve, pero no suficientemente informativa. No se habla del entrevistado, sino del tema principal de la entrevista.
@ El cuerpo de la entrevista esta formado por preguntas y las respuestas. Es importante elegir bien las preguntas para que la entrevista sea buena, las preguntas deben ser interesantes para él publico, y adecuadas para el entrevistado trasmita sus experiencias. También deben ser breves y claras.
@ El cierre de la entrevista debe ser conciso. El entrevistador puede presentar un resumen de lo hablado o hacer un breve comentario personal.
Tipos de entrevistas
La entrevista dirigida o estructurada, que sigue un esquema de preguntas con el objeto de obtener determinada información.
La entrevista no dirigida o no estructurada, donde el informante tiene total libertad para narrar sus experiencias, dar sus opiniones, etc. En este tipo de entrevistas el investigador, utilizando muy pocas preguntas en su oportunidad debida, evita que el entrevistado trate temas no relacionados con el problema motivo de estudio.
Existen otros tipos de entrevistas que se derivan de las anteriores :
a) Panel (Repetir a las mismas personas las mismas preguntas en diferentes tiempos y repreguntar en base a sus respuestas).
b) Focalizada (referida sólo a un aspecto determinado).
c) Repetida (se parece al Panel, sólo que se hace con distintas de personas).
Ventajas de la entrevista
Es más flexible que el cuestionario para obtener información; tanto en la búsqueda de datos
detallados como en la adaptación de las preguntas según las características del entrevistado.
La posibilidad de no obtener información en la entrevista por lo general es menor, con relación al cuestionario, por su misma naturaleza flexible. De igual manera en la entrevista generalmente es menor la posibilidad de perder información en comparación al cuestionario.
Permite obtener mucha mayor información que el cuestionario. Se adecua con mucha más facilidad que el cuestionario a cualquier nivel cultural del informante.
Desventajas de la entrevista
Es más costosa que el cuestionario; sobre todo para muestras grandes, y con mayor razón si los individuos están dispersos geográficamente; por cuanto exige la presencia de entrevistadores. En el caso del cuestionario auto administrado, éste puede ser enviado por correo. Se necesita de entrevistadores altamente especializados en el tema de investigación; es decir, personas muy bien entrenadas en el tema de la entrevista que le permita profundizar en la búsqueda del dato a partir de las respuestas dadas por el informante. La entrevista generalmente requiere de mayor tiempo que el cuestionario. La abundante información recolectada dificulta su registro y puede ser fuente de error en el análisis. El entrevistador, por la flexibilidad de la técnica, puede influenciar en las respuestas del informante.
La abundante información que se obtiene mediante la entrevista hace más costosa su
sistematización y procesamiento estadístico. En la entrevista hay el riesgo de interpretar las respuestas, y a partir de ellas hacer repreguntas.
Es una técnica para recopilar información a partir de un intercambio directo entre personas o grupos. Es uno de los métodos mas populares. El objetivo de una entrevista es buscar hechos (realidad objetiva) los cuales los tiene otra persona.Su fase de recolección de datos se obtiene mediante un conjunto de preguntas, orales o escritos, que se les hace a las personas involucradas en el problema motivo de estudio.
EL ENTREVISTADO debe ser siempre una persona que interese a la comunidad. El entrevistado es la persona que tiene alguna idea o alguna experiencia importante que transmitir.
EL ENTREVISTADOR es el que dirige la entrevista debe dominar el dialogo, presenta al entrevistado y el tema principal, hace preguntas adecuadas y cierra la entrevista.
PARTES DE UNA ENTREVISTA.
@ La presentación debe ser breve, pero no suficientemente informativa. No se habla del entrevistado, sino del tema principal de la entrevista.
@ El cuerpo de la entrevista esta formado por preguntas y las respuestas. Es importante elegir bien las preguntas para que la entrevista sea buena, las preguntas deben ser interesantes para él publico, y adecuadas para el entrevistado trasmita sus experiencias. También deben ser breves y claras.
@ El cierre de la entrevista debe ser conciso. El entrevistador puede presentar un resumen de lo hablado o hacer un breve comentario personal.
Tipos de entrevistas
La entrevista dirigida o estructurada, que sigue un esquema de preguntas con el objeto de obtener determinada información.
La entrevista no dirigida o no estructurada, donde el informante tiene total libertad para narrar sus experiencias, dar sus opiniones, etc. En este tipo de entrevistas el investigador, utilizando muy pocas preguntas en su oportunidad debida, evita que el entrevistado trate temas no relacionados con el problema motivo de estudio.
Existen otros tipos de entrevistas que se derivan de las anteriores :
a) Panel (Repetir a las mismas personas las mismas preguntas en diferentes tiempos y repreguntar en base a sus respuestas).
b) Focalizada (referida sólo a un aspecto determinado).
c) Repetida (se parece al Panel, sólo que se hace con distintas de personas).
Ventajas de la entrevista
Es más flexible que el cuestionario para obtener información; tanto en la búsqueda de datos
detallados como en la adaptación de las preguntas según las características del entrevistado.
La posibilidad de no obtener información en la entrevista por lo general es menor, con relación al cuestionario, por su misma naturaleza flexible. De igual manera en la entrevista generalmente es menor la posibilidad de perder información en comparación al cuestionario.
Permite obtener mucha mayor información que el cuestionario. Se adecua con mucha más facilidad que el cuestionario a cualquier nivel cultural del informante.
Desventajas de la entrevista
Es más costosa que el cuestionario; sobre todo para muestras grandes, y con mayor razón si los individuos están dispersos geográficamente; por cuanto exige la presencia de entrevistadores. En el caso del cuestionario auto administrado, éste puede ser enviado por correo. Se necesita de entrevistadores altamente especializados en el tema de investigación; es decir, personas muy bien entrenadas en el tema de la entrevista que le permita profundizar en la búsqueda del dato a partir de las respuestas dadas por el informante. La entrevista generalmente requiere de mayor tiempo que el cuestionario. La abundante información recolectada dificulta su registro y puede ser fuente de error en el análisis. El entrevistador, por la flexibilidad de la técnica, puede influenciar en las respuestas del informante.
La abundante información que se obtiene mediante la entrevista hace más costosa su
sistematización y procesamiento estadístico. En la entrevista hay el riesgo de interpretar las respuestas, y a partir de ellas hacer repreguntas.
jueves, 22 de octubre de 2009
Síntesis modelos del proceso del software
MODELOS DEL PROCESO DEL SOFTWARE
Es importante definir antes que nada, lo que es un proceso y mas específicamente un modelo de proceso de software, un proceso es un conjunto estructurado de actividades para especificar, diseñar, implementar y probar Sistemas de software. El modelo de proceso de software es una representación abstracta de un proceso. Este representa una descripción de un proceso desde una perspectiva particular.
Se selecciona un modelo de proceso según la naturaleza del proyecto, de la aplicación, los métodos, las herramientas a utilizar, los controles y las entregas que se requieren. Cada modelo ayuda al control y coordinación de un proyecto de software real.
MODELO EN CASCADA
El modelo en cascada original se desarrollo entre las décadas de los sesenta y setenta y se define como una secuencia de actividades, donde la estrategia principal es seguir el proceso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.
Este modelo ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de una etapa debe esperar a la finalización de la etapa inmediatamente anterior.
Algunas de las características más importantes de este modelo son:
Es el más utilizado
Todas las etapas deben desarrollarse para que el proyecto tenga éxito
Las fases continúan hasta que el objetivo es cumplido
Si se cambia el orden de las fases, el producto será de menor calidad
Las fases del modelo en cascada son:
Análisis de requisitos: En esta etapa se analizan los requerimientos de los usuarios finales para determinar los objetivos que deseamos alcanzar.
Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Programación.
Programación: Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos. Muchas veces se realizan pruebas con algunos de los futuros usuarios del sistema para verificar que el mismo sea fácil de entender y utilizar por ellos.
Implantación: El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.
Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:
Mantenimiento Preventivo y Perfectivo
Mantenimiento Correctivo
Mantenimiento Evolutivo
Ventajas del modelo en cascada
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas
Evita una fuente común de errores importantes
Se utiliza correctamente para ciclos en los que se tiene una definición estable del producto.
Desventajas del modelo en cascada
No existe un proyecto “enseñable” hasta el final del proyecto
Se tarda mucho tiempo en pasar por todo el ciclo
Dificultad para especificar claramente los requerimientos al comienzo del proyecto(no permite flexibilidad en los cambios)
Este es una ejemplificación grafica del modelo en cascada
MODELO EN ESPIRAL
Las actividades de este modelo se conforman en una espiral, en la que cada iteración representa a un conjunto de actividades.
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 del sistema diseñado.
Se dice que el modelo en espiral mejora al modelo en cascada enfatizando la naturaleza iterativa del proceso de diseño.
Este modelo sigue algunos principios básicos como por ejemplo:
Definir el problema que se requiere resolver
Examinar las distintas alternativas de acción y elegir la mas conveniente
Conocer los niveles de riesgo
En cada iteración del modelo debemos tomar en cuenta:
Los objetivos: Que es lo que debe resolver nuestro producto
Alternativas: Son las distintas formas que tenemos para conseguir los objetivos de forma exitosa
Desarrollo y Verificación: Programar y probar el software
Para cada ciclo del modelo en espiral hay cuatro actividades:
· Determinar o fijar objetivos: Determinar que producto deseamos obtener, los requerimientos y la especificación.
· Análisis del riesgo: Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
· Desarrollar, verificar y validar (probar)
· Planificar: Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
Ventajas del modelo en espiral
Reduce riesgos del proyecto
Integra el desarrollo con el mantenimiento
Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas.
Desventajas del modelo en espiral
Consume muchos recursos
Genera mucho tiempo en el desarrollo del sistema
Costoso
Requiere experiencia en la identificación de riesgos
MODELO INCREMENTAL
El modelo incremental es un desarrollo inicial de la arquitectura completa del sistema, seguido de incrementos y versiones parciales del mismo. Cada incremento tiene su propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la versión con las demás versiones ya completadas del sistema.
En una visión genérica, el proceso se divide en cuatro partes: Análisis, Diseño, Código, Prueba. En este método se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluyo o desecha elementos al final de cada incremento con la finalidad de que el software se adapte mejor a sus necesidades reales.
Algunas características de este modelo son:
El primer incremento es a menudo un producto esencial
A partir de la evaluación se planea el siguiente incremento y así sucesivamente
Es iterativo por naturaleza
Es útil cuando el personal no es suficiente
La administración de proyectos es más fácil de lograr en incrementos más pequeños
En lugar de entregar el sistema en una sola entrega, el desarrollo y la entrega están facturados bajo incrementos, con cada incremento se entrega parte de la funcionalidad requerida.
Ventajas del modelo incremental
Algunas de las ventajas de este modelo son:
El usuario se involucra mas
Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
Se puede financiar el proyecto por partes
Es apropiado para proyectos grandes, de larga duración
No se necesita tanto personal al principio como para una implementación completa
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
Desventajas del modelo incremental
Estas son algunas de las desventajas de este modelo:
Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.
Representación grafica del modelo incremental:
MODELO RUP
El proceso unificado racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar mas utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Consiste en un conjunto de actividades necesarias para transformar los requerimientos del usuario en el sistema de software. Esta especializado para diversos tipos de software de sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos.
El modelo RUP es una guía de cómo usar UML de la forma más efectiva.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
El ciclo de vida del modelo RUP son:
Inicio: Define el alcance y objetivos del proyecto
Elaboración: Plan de proyecto, especificación de características y arquitectura base.
Construcción: Construir y operar el producto
Transición: garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Algunas de las principales características de este modelo son:
Tiene una forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Es iterativo
Esta guiado por los casos de uso
Incluye artefactos (que son los productos tangibles del proceso)
Incluye roles (es el papel que desempeña una persona en un determinado momento)
Dirigido por casos de uso
Las fases del modelo RUP son:
Establecer oportunidad y alcance
Identificar las entidades externas o actores con los que se trata
Identificar los casos de uso
Ventajas del modelo RUP
Estas son algunas de las ventajas del modelo RUP:
Mitigacion temprana de posibles riesgos altos
Progreso visible en las etapas tempranas
El conocimiento adquirido en una iteración puede aplicarse de iteración a iteración
Los usuarios están involucrados continuamente
Desventajas del modelo RUP
Estas son algunas de las desventajas del modelo RUP:
Por el grado de complejidad puede no resultar muy adecuado.
El RUP es generalmente mal aplicado en el estilo cascada.
Requiere conocimientos del proceso y de UML.
Es importante definir antes que nada, lo que es un proceso y mas específicamente un modelo de proceso de software, un proceso es un conjunto estructurado de actividades para especificar, diseñar, implementar y probar Sistemas de software. El modelo de proceso de software es una representación abstracta de un proceso. Este representa una descripción de un proceso desde una perspectiva particular.
Se selecciona un modelo de proceso según la naturaleza del proyecto, de la aplicación, los métodos, las herramientas a utilizar, los controles y las entregas que se requieren. Cada modelo ayuda al control y coordinación de un proyecto de software real.
MODELO EN CASCADA
El modelo en cascada original se desarrollo entre las décadas de los sesenta y setenta y se define como una secuencia de actividades, donde la estrategia principal es seguir el proceso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.
Este modelo ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de una etapa debe esperar a la finalización de la etapa inmediatamente anterior.
Algunas de las características más importantes de este modelo son:
Es el más utilizado
Todas las etapas deben desarrollarse para que el proyecto tenga éxito
Las fases continúan hasta que el objetivo es cumplido
Si se cambia el orden de las fases, el producto será de menor calidad
Las fases del modelo en cascada son:
Análisis de requisitos: En esta etapa se analizan los requerimientos de los usuarios finales para determinar los objetivos que deseamos alcanzar.
Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Programación.
Programación: Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos. Muchas veces se realizan pruebas con algunos de los futuros usuarios del sistema para verificar que el mismo sea fácil de entender y utilizar por ellos.
Implantación: El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.
Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:
Mantenimiento Preventivo y Perfectivo
Mantenimiento Correctivo
Mantenimiento Evolutivo
Ventajas del modelo en cascada
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas
Evita una fuente común de errores importantes
Se utiliza correctamente para ciclos en los que se tiene una definición estable del producto.
Desventajas del modelo en cascada
No existe un proyecto “enseñable” hasta el final del proyecto
Se tarda mucho tiempo en pasar por todo el ciclo
Dificultad para especificar claramente los requerimientos al comienzo del proyecto(no permite flexibilidad en los cambios)
Este es una ejemplificación grafica del modelo en cascada
MODELO EN ESPIRAL
Las actividades de este modelo se conforman en una espiral, en la que cada iteración representa a un conjunto de actividades.
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 del sistema diseñado.
Se dice que el modelo en espiral mejora al modelo en cascada enfatizando la naturaleza iterativa del proceso de diseño.
Este modelo sigue algunos principios básicos como por ejemplo:
Definir el problema que se requiere resolver
Examinar las distintas alternativas de acción y elegir la mas conveniente
Conocer los niveles de riesgo
En cada iteración del modelo debemos tomar en cuenta:
Los objetivos: Que es lo que debe resolver nuestro producto
Alternativas: Son las distintas formas que tenemos para conseguir los objetivos de forma exitosa
Desarrollo y Verificación: Programar y probar el software
Para cada ciclo del modelo en espiral hay cuatro actividades:
· Determinar o fijar objetivos: Determinar que producto deseamos obtener, los requerimientos y la especificación.
· Análisis del riesgo: Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
· Desarrollar, verificar y validar (probar)
· Planificar: Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
Ventajas del modelo en espiral
Reduce riesgos del proyecto
Integra el desarrollo con el mantenimiento
Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas.
Desventajas del modelo en espiral
Consume muchos recursos
Genera mucho tiempo en el desarrollo del sistema
Costoso
Requiere experiencia en la identificación de riesgos
MODELO INCREMENTAL
El modelo incremental es un desarrollo inicial de la arquitectura completa del sistema, seguido de incrementos y versiones parciales del mismo. Cada incremento tiene su propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la versión con las demás versiones ya completadas del sistema.
En una visión genérica, el proceso se divide en cuatro partes: Análisis, Diseño, Código, Prueba. En este método se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluyo o desecha elementos al final de cada incremento con la finalidad de que el software se adapte mejor a sus necesidades reales.
Algunas características de este modelo son:
El primer incremento es a menudo un producto esencial
A partir de la evaluación se planea el siguiente incremento y así sucesivamente
Es iterativo por naturaleza
Es útil cuando el personal no es suficiente
La administración de proyectos es más fácil de lograr en incrementos más pequeños
En lugar de entregar el sistema en una sola entrega, el desarrollo y la entrega están facturados bajo incrementos, con cada incremento se entrega parte de la funcionalidad requerida.
Ventajas del modelo incremental
Algunas de las ventajas de este modelo son:
El usuario se involucra mas
Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
Se puede financiar el proyecto por partes
Es apropiado para proyectos grandes, de larga duración
No se necesita tanto personal al principio como para una implementación completa
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
Desventajas del modelo incremental
Estas son algunas de las desventajas de este modelo:
Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.
Representación grafica del modelo incremental:
MODELO RUP
El proceso unificado racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar mas utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Consiste en un conjunto de actividades necesarias para transformar los requerimientos del usuario en el sistema de software. Esta especializado para diversos tipos de software de sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos.
El modelo RUP es una guía de cómo usar UML de la forma más efectiva.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
El ciclo de vida del modelo RUP son:
Inicio: Define el alcance y objetivos del proyecto
Elaboración: Plan de proyecto, especificación de características y arquitectura base.
Construcción: Construir y operar el producto
Transición: garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Algunas de las principales características de este modelo son:
Tiene una forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Es iterativo
Esta guiado por los casos de uso
Incluye artefactos (que son los productos tangibles del proceso)
Incluye roles (es el papel que desempeña una persona en un determinado momento)
Dirigido por casos de uso
Las fases del modelo RUP son:
Establecer oportunidad y alcance
Identificar las entidades externas o actores con los que se trata
Identificar los casos de uso
Ventajas del modelo RUP
Estas son algunas de las ventajas del modelo RUP:
Mitigacion temprana de posibles riesgos altos
Progreso visible en las etapas tempranas
El conocimiento adquirido en una iteración puede aplicarse de iteración a iteración
Los usuarios están involucrados continuamente
Desventajas del modelo RUP
Estas son algunas de las desventajas del modelo RUP:
Por el grado de complejidad puede no resultar muy adecuado.
El RUP es generalmente mal aplicado en el estilo cascada.
Requiere conocimientos del proceso y de UML.
Unidad 2 cont
2.7 Software de Alta Calidad
La calidad del software es un objetivo al que se dedican muchos esfuerzos. Es muy difícil poder crear software perfecto. Pero todo proyecto tiene como objetivo producir software de la mejor calidad posible.
Antes de adentrarnos de lleno a este tema, seria bueno definir el concepto de calidad.
Calidad: La calidad es la aptitud de un producto para satisfacer las necesidades del usuario. Algunos de los aspectos que se pueden tomar en cuenta para evaluar la calidad del software son:
Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Para poder asegurar la calidad del software, debemos tener un conjunto de actividades planificadas y sistematizadas, que son necesarias para aportar la confianza en que el producto satisface los requisitos de calidad.
No podemos certificar la calidad del software, pero lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, etc.).
ISO 9000: Las normas ISO 9000, son normas de calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (ISO). Se pueden aplicar en cualquier tipo de organización o actividad sistemática orientada a la producción de bienes o servicios. Se componen de estándares y guías relacionados con sistemas de gestión y de herramientas específicas, como los métodos de auditoria.
En cuanto al software, pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%. Audita al sistema. Si los resultados son positivos emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es un proceso costoso.
El nacimiento de CMM-CMMI
El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas.
Convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos problemas", se presentaron diversas solicitudes y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM – CMMI.
CMM-CMMI: El CMM (Capability Maturity Model) – CMMI (Capability Maturity Model Integration) es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
Las siglas CMM significan Modelo de capacidad y madurez, y CMMI seria en español algo como integración del modelo de madurez de capacidad.
El modelo CMM establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
Definidas en un proceso documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas
Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido.
Nivel Inicial o Nivel Uno: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.
El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Nivel Repetible o Nivel Dos: En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Nivel Definido o Nivel Tres: Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
Resumiéndolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Nivel Gestionado o Nivel Cuatro: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Nivel Optimizado o Nivel Cinco: La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.
Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causas
Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
2.8 Factores de calidad y productividad
En los modelos de calidad, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se van a evaluar a través de un conjunto de indicadores o métricas.
Tienen una estructura, por lo general, en tres niveles:
Factores de Calidad
Criterios de calidad del Producto
Métricas del Producto
En el nivel más alto de la jerarquía se encuentran los factores de calidad, que representan la calidad desde el punto de vista del usuario.
Cada uno de los factores se descompone en un conjunto de criterios de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software.
Para cada uno de los criterios de calidad se definen entonces un conjunto de métricas, que son medidas cuantitativas de ciertas características del producto que dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.
Factores de calidad del software de McCall
Este modelo es considerado por primera vez en 1977 por McCall. Destinado a ser utilizado durante el proceso de desarrollo de sistemas, sirvió desde muy temprano como puente entre los usuarios y los desarrolladores, concilia los puntos de la vista de los usuarios con las prioridades de los desarrolladores. Con una perspectiva de visión basada en los criterios de la evaluación de la calidad.
El modelo de calidad de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto.
Operación del producto
Revisión del producto
Transición del producto
Este modelo se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente manera:
v Operación de producto ó Características operacionales
§ Facilidad de uso (¿Puedo ejecutarlo?)
§ Integridad (¿Es seguro?)
§ Corrección (¿Hace el software lo que yo quiero?)
§ Fiabilidad (¿Lo hace de forma exacta todo el T?)
§ Eficiencia (¿Se ejecutará sobre mi HW lo mejor posible?)
v Revisión del producto ó Capacidad de soportar cambios
§ Facilidad de mantenimiento (¿Puedo arreglarlo?)
§ Facilidad de prueba (¿Puedo probarlo?)
§ Flexibilidad (¿Puedo modificarlo?)
v Transición del producto ó Adaptabilidad de nuevos entornos
§ Facilidad de reutilización (¿Podré reutilizar parte del software?)
§ Interoperabilidad (¿Podré comunicarlo con otros sistemas?)
§ Portabilidad (¿Podré utilizarlo en otra máquina?)
Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Ahora se enlistan algunas de estas métricas:
Facilidad de Auditoria: La facilidad con que se puede comprobar la conformidad con los estándares
Exactitud: La precisión de los cálculos y el control
Normalización de las Comunicaciones: El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
Completitud: El grado en que se ha conseguido la total implementación de las funciones requeridas
Concisión: Lo compacto que es el programa en términos de líneas de código
Consistencia: El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
Estandarización en los datos: El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
Tolerancia de Errores: El daño que se produce cuando el programa encuentra un error
Eficiencia en la Ejecución: El rendimiento en tiempo de ejecución de un programa
Facilidad de expansión: El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
Generalidad: La amplitud de aplicación potencial de los componentes del programa
Independencia del Hardware: El grado en que el software es independiente del hardware en que opera
Instrumentación: El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
Modularidad: La independencia funcional de los componentes del programa
Facilidad de Operación: La facilidad de operación de un programa
Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o datos
Auto-Documentación: El grado en que el código fuente proporciona documentación significativa.
La siguiente imagen muestra la relación que existe entre los factores, criterios y métricas en el modelo de McCall:
La calidad del software es un objetivo al que se dedican muchos esfuerzos. Es muy difícil poder crear software perfecto. Pero todo proyecto tiene como objetivo producir software de la mejor calidad posible.
Antes de adentrarnos de lleno a este tema, seria bueno definir el concepto de calidad.
Calidad: La calidad es la aptitud de un producto para satisfacer las necesidades del usuario. Algunos de los aspectos que se pueden tomar en cuenta para evaluar la calidad del software son:
Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Para poder asegurar la calidad del software, debemos tener un conjunto de actividades planificadas y sistematizadas, que son necesarias para aportar la confianza en que el producto satisface los requisitos de calidad.
No podemos certificar la calidad del software, pero lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, etc.).
ISO 9000: Las normas ISO 9000, son normas de calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (ISO). Se pueden aplicar en cualquier tipo de organización o actividad sistemática orientada a la producción de bienes o servicios. Se componen de estándares y guías relacionados con sistemas de gestión y de herramientas específicas, como los métodos de auditoria.
En cuanto al software, pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%. Audita al sistema. Si los resultados son positivos emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es un proceso costoso.
El nacimiento de CMM-CMMI
El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas.
Convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos problemas", se presentaron diversas solicitudes y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM – CMMI.
CMM-CMMI: El CMM (Capability Maturity Model) – CMMI (Capability Maturity Model Integration) es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
Las siglas CMM significan Modelo de capacidad y madurez, y CMMI seria en español algo como integración del modelo de madurez de capacidad.
El modelo CMM establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
Definidas en un proceso documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas
Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido.
Nivel Inicial o Nivel Uno: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.
El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Nivel Repetible o Nivel Dos: En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Nivel Definido o Nivel Tres: Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
Resumiéndolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Nivel Gestionado o Nivel Cuatro: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Nivel Optimizado o Nivel Cinco: La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.
Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causas
Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
2.8 Factores de calidad y productividad
En los modelos de calidad, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se van a evaluar a través de un conjunto de indicadores o métricas.
Tienen una estructura, por lo general, en tres niveles:
Factores de Calidad
Criterios de calidad del Producto
Métricas del Producto
En el nivel más alto de la jerarquía se encuentran los factores de calidad, que representan la calidad desde el punto de vista del usuario.
Cada uno de los factores se descompone en un conjunto de criterios de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software.
Para cada uno de los criterios de calidad se definen entonces un conjunto de métricas, que son medidas cuantitativas de ciertas características del producto que dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.
Factores de calidad del software de McCall
Este modelo es considerado por primera vez en 1977 por McCall. Destinado a ser utilizado durante el proceso de desarrollo de sistemas, sirvió desde muy temprano como puente entre los usuarios y los desarrolladores, concilia los puntos de la vista de los usuarios con las prioridades de los desarrolladores. Con una perspectiva de visión basada en los criterios de la evaluación de la calidad.
El modelo de calidad de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto.
Operación del producto
Revisión del producto
Transición del producto
Este modelo se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente manera:
v Operación de producto ó Características operacionales
§ Facilidad de uso (¿Puedo ejecutarlo?)
§ Integridad (¿Es seguro?)
§ Corrección (¿Hace el software lo que yo quiero?)
§ Fiabilidad (¿Lo hace de forma exacta todo el T?)
§ Eficiencia (¿Se ejecutará sobre mi HW lo mejor posible?)
v Revisión del producto ó Capacidad de soportar cambios
§ Facilidad de mantenimiento (¿Puedo arreglarlo?)
§ Facilidad de prueba (¿Puedo probarlo?)
§ Flexibilidad (¿Puedo modificarlo?)
v Transición del producto ó Adaptabilidad de nuevos entornos
§ Facilidad de reutilización (¿Podré reutilizar parte del software?)
§ Interoperabilidad (¿Podré comunicarlo con otros sistemas?)
§ Portabilidad (¿Podré utilizarlo en otra máquina?)
Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Ahora se enlistan algunas de estas métricas:
Facilidad de Auditoria: La facilidad con que se puede comprobar la conformidad con los estándares
Exactitud: La precisión de los cálculos y el control
Normalización de las Comunicaciones: El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
Completitud: El grado en que se ha conseguido la total implementación de las funciones requeridas
Concisión: Lo compacto que es el programa en términos de líneas de código
Consistencia: El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
Estandarización en los datos: El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
Tolerancia de Errores: El daño que se produce cuando el programa encuentra un error
Eficiencia en la Ejecución: El rendimiento en tiempo de ejecución de un programa
Facilidad de expansión: El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
Generalidad: La amplitud de aplicación potencial de los componentes del programa
Independencia del Hardware: El grado en que el software es independiente del hardware en que opera
Instrumentación: El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
Modularidad: La independencia funcional de los componentes del programa
Facilidad de Operación: La facilidad de operación de un programa
Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o datos
Auto-Documentación: El grado en que el código fuente proporciona documentación significativa.
La siguiente imagen muestra la relación que existe entre los factores, criterios y métricas en el modelo de McCall:
Unidad 2
2.1 Definición de ingeniería del software
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea flexible y funcione de manera eficiente sobre maquinas reales “
Fritz Barner
La ingeniería de software es una disiplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema, hasta el mantenimiento de este después de que ya se utiliza.
2.2 Historia de la ingeniería del software
La ingeniería en software es una rama muy joven de la ingeniería y por eso se encuentra en un estado de cambio rápido. La British Computer Society, por ejemplo, la primera ocasión en que ofreció el certificado Chartered Engineer a los ingenieros en software, fue al principio de la década de los 90’. En 1998 por primera vez fue posible registrarse como ingeniero de software profesional en un lugar en Estados Unidos.
De cualquier manera al inicio del siglo XXI se reconoce ampliamente que falta una disciplina a la forma en que las organizaciones desarrollan sus aplicaciones de software. Una estimación coloca al 75% de las organizaciones en un nivel primitivo.
2.3 Características del Software
1.- El software se desarrolla, no se fabrica en un sentido clásico
En esta actividad la buena calidad se adquiere mediante un buen diseño, el cual depende de las personas. Los costes de software se encuentran en la ingeniería, esto significa, que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
2.- El software no se estropea
El software no es susceptible a los mates del entorno que hacen que el hardware se estropee, por tanto la curva de fallos para el software al inicio puede tener un máximo pero después se minimiza y estabiliza.
3.- La mayoría del software se construye a la medida en vez de ensamblar componentes existentes
Con pocas excepciones no existen catálogos de componentes de software, se puede comprar software ya desarrollado pero solo como una unidad completa, no como componentes que pueden ser ensamblables en nuevos programas. Aunque se ha escrito mucho sobre reusabilidad del software solo estamos comenzando a ver las primeras implementaciones con éxito de este concepto.
2.4 Mitos del software
Mitos de Gestión
- Se cuenta con documentación y procedimientos para construir cualquier software.
- Tener computadoras muy potentes garantiza el desarrollo del software a través de desarrollo de herramientas CASE.
- Horda mongoliana
Mitos de Gestión
- Solo los objetivos generales importan para empezar a desarrollar
- Que el software es flexible y pueden hacerse cambios fácilmente.
Mitos de los desarrolladores
- Solo con hacer funcionar los programas es suficiente
- Solo se ve la calidad del software ejecutando el programa
- Solo se entrega el programa al terminar el proyecto
2.5 Capas de la ingeniería del Software
Independientemente da la complejidad del sistema la ingeniería de software puede considerarse una tecnología multicapa donde la primera capa enfatiza los cimientos de la ingeniería de software está orientada a la calidad.
Donde el proceso es el conjunto de actividades, métodos, práctica y tecnologías aplicables a todos los proyectos de software.
Los métodos o modelos de la ingeniería de software indica cómo realizar los pasos necesarios del ciclo de vida.
Las herramientas ayudan a organizar tareas de trabajo, controlar y supervisar los procesos y administrar la calidad técnica. Su objetivo principal es proporcionar un soporte automático o semiautomático, para los métodos y para los procesos.
2.6 El proceso del software
Un proceso del software es u conjunto de actividades y resultados asociados que producen un producto de software.
Existen cuatro actividades fundamentales del proceso que son comunes para todos los proceso del software:
1.- Especificación del software: Donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación.
2.- Desarrollo del software: Donde el Software se diseña y se programa
3.- Validación del Software: Donde el software se valida para asegurar que es lo que el cliente requiere.
4.- Evaluación del Software: Donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado.
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea flexible y funcione de manera eficiente sobre maquinas reales “
Fritz Barner
La ingeniería de software es una disiplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema, hasta el mantenimiento de este después de que ya se utiliza.
2.2 Historia de la ingeniería del software
La ingeniería en software es una rama muy joven de la ingeniería y por eso se encuentra en un estado de cambio rápido. La British Computer Society, por ejemplo, la primera ocasión en que ofreció el certificado Chartered Engineer a los ingenieros en software, fue al principio de la década de los 90’. En 1998 por primera vez fue posible registrarse como ingeniero de software profesional en un lugar en Estados Unidos.
De cualquier manera al inicio del siglo XXI se reconoce ampliamente que falta una disciplina a la forma en que las organizaciones desarrollan sus aplicaciones de software. Una estimación coloca al 75% de las organizaciones en un nivel primitivo.
2.3 Características del Software
1.- El software se desarrolla, no se fabrica en un sentido clásico
En esta actividad la buena calidad se adquiere mediante un buen diseño, el cual depende de las personas. Los costes de software se encuentran en la ingeniería, esto significa, que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
2.- El software no se estropea
El software no es susceptible a los mates del entorno que hacen que el hardware se estropee, por tanto la curva de fallos para el software al inicio puede tener un máximo pero después se minimiza y estabiliza.
3.- La mayoría del software se construye a la medida en vez de ensamblar componentes existentes
Con pocas excepciones no existen catálogos de componentes de software, se puede comprar software ya desarrollado pero solo como una unidad completa, no como componentes que pueden ser ensamblables en nuevos programas. Aunque se ha escrito mucho sobre reusabilidad del software solo estamos comenzando a ver las primeras implementaciones con éxito de este concepto.
2.4 Mitos del software
Mitos de Gestión
- Se cuenta con documentación y procedimientos para construir cualquier software.
- Tener computadoras muy potentes garantiza el desarrollo del software a través de desarrollo de herramientas CASE.
- Horda mongoliana
Mitos de Gestión
- Solo los objetivos generales importan para empezar a desarrollar
- Que el software es flexible y pueden hacerse cambios fácilmente.
Mitos de los desarrolladores
- Solo con hacer funcionar los programas es suficiente
- Solo se ve la calidad del software ejecutando el programa
- Solo se entrega el programa al terminar el proyecto
2.5 Capas de la ingeniería del Software
Independientemente da la complejidad del sistema la ingeniería de software puede considerarse una tecnología multicapa donde la primera capa enfatiza los cimientos de la ingeniería de software está orientada a la calidad.
Donde el proceso es el conjunto de actividades, métodos, práctica y tecnologías aplicables a todos los proyectos de software.
Los métodos o modelos de la ingeniería de software indica cómo realizar los pasos necesarios del ciclo de vida.
Las herramientas ayudan a organizar tareas de trabajo, controlar y supervisar los procesos y administrar la calidad técnica. Su objetivo principal es proporcionar un soporte automático o semiautomático, para los métodos y para los procesos.
2.6 El proceso del software
Un proceso del software es u conjunto de actividades y resultados asociados que producen un producto de software.
Existen cuatro actividades fundamentales del proceso que son comunes para todos los proceso del software:
1.- Especificación del software: Donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación.
2.- Desarrollo del software: Donde el Software se diseña y se programa
3.- Validación del Software: Donde el software se valida para asegurar que es lo que el cliente requiere.
4.- Evaluación del Software: Donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado.
miércoles, 30 de septiembre de 2009
Caso de la uva
Propuesta de análisis:
Estructurado
Justificación UVA
El sistema a desarrollar se debe hacer porque el solicitante, en este caso el gerente de compras de la empresa, lo requiere para llevar un mejor control de sus pedidos de sus clientes para una entrega oportuna y eficiente, en cuanto a la empresa le beneficiara ya que le permitira tener una mejor organización de sus pedidos y asi poder atender correctamente a sus clientes.
Objetivos:
General: Elaborar un plan de actividades para la solución eficiente del problema propuesto por la compañía la “uva”.
Especifico: Desarrollar el sistema requerido que cumpla con los requerimientos de la compañía, en este caso poder resolver el problema de los pedidos para que se puedan atender de forma eficiente.
Plan de actividades:
-Analizar el problema a detalle entendiendo y ubicando donde se hará el sistema
- Hacer un análisis de factibilidad
-Reunir lo necesario para el desarrollo de dicho sistema en caso de ser aprobado
- Diseñar el sistema a nivel de diagramas para poder mostrarlo al gerente y ver si cumple con sus necesidades para posteriormente poder desarrollarlo. En caso de que no, rectificar los errores.
- Desarrollar el sistema y probarlo con el usuario, si responde a sus requerimientos ya implementarlo
CASO NUMERO 1 (LA ABUELA)
Propuesta de Análisis de sistema en cuestión: Estructurado
Justificación: El sistema que se pretende crear ayudara a optimizar el funcionamiento del negocio en cuestión, así como también puede ser útil para otros negocios parecidos en un futuro.
Objetivos General y Específico: El objetivo general de desarrollar este sistema es facilitar el control de cualquier negocio que incluya entre sus transacciones las entradas y salidas de mercancías, así como facilitar el análisis de la situación del mismo.
El objetivo específico en cuanto al desarrollo de este sistema es hacer que la tienda “La abuela” es que se automaticen todos los procesos que en ella se realizan, así como poder tener información escrita de la situación de su negocio, sus perdidas y ganancias.
Plan de actividades a llevar a cabo para la solución del problema: El plan de actividades propuesto para este caso en específico, consiste en observar físicamente el desarrollo de las actividades dentro de la tienda, es decir el modo en que esta opera. Una vez realizadas las observaciones, podemos desarrollar un diagrama de flujo para darnos una idea de cómo un sistema podría hacer mas fáciles las actividades del negocio. Después de tener bien claro el modo en que esperamos que nuestro sistema trabaje, tenemos que analizar los elementos con los que contamos, el equipo con que se cuenta en la tienda y es presupuesto disponible para el desarrollo del sistema, para decidir entonces si es posible desarrollar el sistema.
Cuando sabemos que el sistema se puede desarrollar debido a que contamos con todos los elementos necesarios para ello, podemos proceder a Diseñar el software, que por último, será implementado en el negocio.
Propuesta de Análisis de sistema en cuestión: Estructurado
Justificación: El sistema que se pretende crear ayudara a optimizar el funcionamiento del negocio en cuestión, así como también puede ser útil para otros negocios parecidos en un futuro.
Objetivos General y Específico: El objetivo general de desarrollar este sistema es facilitar el control de cualquier negocio que incluya entre sus transacciones las entradas y salidas de mercancías, así como facilitar el análisis de la situación del mismo.
El objetivo específico en cuanto al desarrollo de este sistema es hacer que la tienda “La abuela” es que se automaticen todos los procesos que en ella se realizan, así como poder tener información escrita de la situación de su negocio, sus perdidas y ganancias.
Plan de actividades a llevar a cabo para la solución del problema: El plan de actividades propuesto para este caso en específico, consiste en observar físicamente el desarrollo de las actividades dentro de la tienda, es decir el modo en que esta opera. Una vez realizadas las observaciones, podemos desarrollar un diagrama de flujo para darnos una idea de cómo un sistema podría hacer mas fáciles las actividades del negocio. Después de tener bien claro el modo en que esperamos que nuestro sistema trabaje, tenemos que analizar los elementos con los que contamos, el equipo con que se cuenta en la tienda y es presupuesto disponible para el desarrollo del sistema, para decidir entonces si es posible desarrollar el sistema.
Cuando sabemos que el sistema se puede desarrollar debido a que contamos con todos los elementos necesarios para ello, podemos proceder a Diseñar el software, que por último, será implementado en el negocio.
Proyecto
Proyecto:
Implementacion de un sistema computacional para el control de produccion de una panaderia, que actualmente lleva toda la informacion en papel.
Justificacion
Aunque pareciera que es un sistema de inventario o de punto de venta que ya existen en el mercado, se tiene la posibilidad de implementarlo, en su totalidad, en una empresa que realmente existe llevando a la practica los conocimientos, adquiridos en la aula, aun nivel fisico y tangible. Con ello no solo se pretende beneficiar a la empresa, si no tambien el aprender de hechos reales los contratiempos que pudieran surgir.
Objetivos generales y particulares
Generale: Desarrollar un sistema de control de produccion para una panaderia, que de informes de ventas y de produccion a travez de internet.
Especificos :
- Tener informacion especifica que nos ayude a determinar la cantidad exacta que se requiere de produccion.
- Determinar la cantidad de venta que se tiene por ruta o empleado, cliente, mayoristas y locales.
- Determinar al pago del personal que trabaja a comision.
- Contar con estadisticas de venta.
- Contar con catalogo de clientes y provedores
Plan de actividades a llevar acabo para la solucio del problema
- Es necesario primeramente determinar los requerimientos de la empresa en cuanto a informacion, asi que se recabara mediante, el seguimiento del proceso que se lleva actualmente acabo.
- Se describiran las especificaciones que se desean que cuente el sistema , asi como la forma en que interactuara con los clientes, empleados, provedores y administrativos.
- Determinar que tipo de informacion debe de registrarse en el sistema, asi como los tipos de informes que este desplegara.
- Se analizara atravez de diferentes diagramas y estructuras el flujo de informacion para determinar la mejor manera de estructurar el sistema .
- Se pondra a prueba para determinar lo que le haga falta asi como tambien se le dara mantenimiento constante.
Implementacion de un sistema computacional para el control de produccion de una panaderia, que actualmente lleva toda la informacion en papel.
Justificacion
Aunque pareciera que es un sistema de inventario o de punto de venta que ya existen en el mercado, se tiene la posibilidad de implementarlo, en su totalidad, en una empresa que realmente existe llevando a la practica los conocimientos, adquiridos en la aula, aun nivel fisico y tangible. Con ello no solo se pretende beneficiar a la empresa, si no tambien el aprender de hechos reales los contratiempos que pudieran surgir.
Objetivos generales y particulares
Generale: Desarrollar un sistema de control de produccion para una panaderia, que de informes de ventas y de produccion a travez de internet.
Especificos :
- Tener informacion especifica que nos ayude a determinar la cantidad exacta que se requiere de produccion.
- Determinar la cantidad de venta que se tiene por ruta o empleado, cliente, mayoristas y locales.
- Determinar al pago del personal que trabaja a comision.
- Contar con estadisticas de venta.
- Contar con catalogo de clientes y provedores
Plan de actividades a llevar acabo para la solucio del problema
- Es necesario primeramente determinar los requerimientos de la empresa en cuanto a informacion, asi que se recabara mediante, el seguimiento del proceso que se lleva actualmente acabo.
- Se describiran las especificaciones que se desean que cuente el sistema , asi como la forma en que interactuara con los clientes, empleados, provedores y administrativos.
- Determinar que tipo de informacion debe de registrarse en el sistema, asi como los tipos de informes que este desplegara.
- Se analizara atravez de diferentes diagramas y estructuras el flujo de informacion para determinar la mejor manera de estructurar el sistema .
- Se pondra a prueba para determinar lo que le haga falta asi como tambien se le dara mantenimiento constante.
viernes, 18 de septiembre de 2009
jueves, 17 de septiembre de 2009
Fundamento de desarrollo de sistemas
Es un gran placer iniciar esta página que esperemos sea el resultado de muchas horas de estudio y que además podamos aportar algo importante al resto de nuestros compañeros…
Como ya se dijo el blog está dirigido a la materia de Fundamentos de desarrollo del software, pero principalmente a reflejar nuestras experiencias y vivencias a lo largo de este curso, además de la evolución de nuestro proyecto…
Esperamos sea de gran utilidad lo que poco a poco iremos desarrollando…
Eloísa Marroquín Cabrera
Maricela Santiago Cayetano
Sánchez García Gerardo Alonso
Como ya se dijo el blog está dirigido a la materia de Fundamentos de desarrollo del software, pero principalmente a reflejar nuestras experiencias y vivencias a lo largo de este curso, además de la evolución de nuestro proyecto…
Esperamos sea de gran utilidad lo que poco a poco iremos desarrollando…
Eloísa Marroquín Cabrera
Maricela Santiago Cayetano
Sánchez García Gerardo Alonso
Suscribirse a:
Entradas (Atom)
