SISTEMA DE INFORMACIÓN ONLINE

SEGUNDA COMPETENCIA: SISTEMA DE INFORMACIÓN ONLINE PARA LA BIBLIOTECA VIRTUAL

AUTORES:

SANTIAGO QUINTANA ROA
KEVEN STEVEN HOYOS GOMEZ
DANIEL ANTONIO GONZALEZ AMAYA
JOHAN SEBASTIAN BOCANEGRA SANCHEZ

SENA: CENTRO DE LA INDUSTRIA Y LA CONSTRUCCIÓN
ADSI
TOLIMA
APRENDIZ
IBAGUÉ
2016

SEGUNDA COMPETENCIA: SISTEMA DE INFORMACIÓN ONLINE PARA LA BIBLIOTECA VIRTUAL

AUTORES:

SANTIAGO QUINTANA ROA
KEVEN STEVEN HOYOS GOMEZ
DANIEL ANTONIO GONZALEZ AMAYA
JOHAN SEBASTIAN BOCANEGRA SANCHEZ

INSTRUCTOR:

PABLO CESAR MONROY MARIN

SENA: CENTRO DE LA INDUSTRIA Y LA CONSTRUCCIÓN
ADSI
TOLIMA
APRENDIZ
IBAGUÉ
2016

3.1. Reflexión

• ¿Cuáles son los modelos a seguir en el establecimiento de un proceso?

R/ Modelos de ciclos de vida espiral

• ¿Qué procesos mejoran la productividad y calidad?

R/ Los procesos reproducibles y predecibles

• ¿Por qué no se cumplen los proyectos de software?

R/ Por una gestión de proyectos no efectiva.

3.2.

3.1.3. Cuadro Sinóptico         [pic 1]

3.1.5 REQUERIMIENTOS DE SOFTWARE – RESUMEN

El proceso de analizar, recolectar y verificar las necesidades del cliente es conocido como ingeniería de requerimientos, cumple un papel importan puesto que su trabajo es describir de una forma clara y concisa el software a desarrollar.

Se tiene estimado que un 53 % de los proyectos de software fracasan por no realizar un estudio previo de los requerimientos y falta de la participación del cliente.

• Requerimientos

Es la necesidad que presenta el cliente y que debe estar presente en un contrato o algún documento formal

• Requerimientos funcionales:

Definen: las funciones que el sistema podrá hacer, las transformaciones de entradas en salidas.

• Requerimientos no funcionales:

Definen: Las características que pueden limitar al sistema como: Rendimiento, interfaces, fiabilidad, mantenimiento, etc.

• Características de los requerimientos

• Necesario: Es necesario cuando es irremplazable, por que pueda provocar algún tipo de deficiencia en el sistema.
• Conciso: Se es conciso cuando se es fácil de leer por su estructura simple y clara.
• Completo: Esta completo cuando tiene la información suficiente como para no ampliar más el tema.
• Consistente: Que no es contradictorio con otro requerimiento.
• No ambiguo: Tiene una sola interpretación, no causa confusión en el lector.
• Verificable: Cuando permita hacer uso de métodos de verificación como: inspección, análisis, demostración, pruebas.

• Dificultades para definir los requerimientos.

• No son obvios, tienen muchas fuentes
• Difíciles de expresar con palabras
• Hay muchos tipos y con diferente tipo de detalle.
• La cantidad de requerimientos puede llegar a ser difícil de manejar.
• Nunca son iguales, otros requieren más prioridad que otros.
• Están relacionados con los mismos y con partes del proceso.
• Tiene propiedades únicas abarcando áreas funcionales específicas.
• Puede cambiar en el desarrollo.
• Difíciles de cuantificar, ya que cada conjunto de requerimientos es diferente para cada proyecto.

• Beneficios de la IR

Beneficios principales:

• Permite gestionar las necesidades del proyecto en forma estructurada.
• Capacidad de predecir proyectos y resultados futuros.
• Disminución de los costos y retrasos del proyecto.
• Mejora de calidad del software.
• Mejora de comunicación entre equipos.
• Evita rechazos de usuarios finales.

• Puntos a considerar en el proceso de IR

• Objetivos del negocio y ambiente de trabajo.

Permite especificar el sistema que será construido.

• Punto de vista de los clientes.

Cada cliente tiene necesidades diferentes, a veces los clientes no son los usuarios y esto crea conflictos con lo que el usuario desea.

• Problemas por el tamaño y complejidad.

Barrearas de comunicación, evolución e integración del sistema, documentación de requerimientos.

• Actividades de la IR

• Análisis del problema
• Evaluación y negociación
• Especificación
• Validación
• Evolución

• Análisis del problema

• Objetivo: Entender las verdaderas necesidades del negocio.
• Comprender el problema que se está resolviendo

Puede haber muchas soluciones, pero solo una será la más adecuada, las soluciones deben tomarse teniendo en cuenta la perspectiva técnica como la del negocio.

• Construir un vocabulario común.

Un glosario es de gran ayuda puesto que ayuda a que todos entiendan lo mismo y sea comprensible reduciendo los términos poco entendibles.

• Identificar los afectados por el sistema

Esto evita que haya sorpresas futuras verificando las necesidades de quienes se ven afectados.

• ¿Quién usará el sistema que se va a construir?
• ¿Quién mercadeará, venderá y o distribuirá el sistema?
• ¿Quién se beneficiará por el retorno de inversión del sistema?

• Definir los límites y restricciones del sistema

Se debe saber:

• Lo que se está construyendo
• Lo que no se está construyendo
• Entender la estrategia del producto a corto y largo plazo
• Debe determinarse cualquier restricción que llegue a limitar el sistema a construir.

• Evaluación y negociación de los requerimientos

• Objetivo: limitar lo que el cliente espera, teniendo como referencia los niveles de abstracción y descomposición de los problemas.
• Descubrir problemas potenciales

Requerimientos ambiguos, incompletos, inconsistentes, etc.

...