Desarrollo De Un Entorno Metodológico De Ingeniería De Requisitos Para Microempresas Desarrolladoras De Software

UNIVERSIDAD CIENTÍFICA DEL PERÚ

FACULTAD DE INGENIERÍA

Desarrollo De Un Entorno Metodológico De Ingeniería De Requisitos Para Microempresas Desarrolladoras De Software

autor:

Bach. ERICK GIOVANNI BORRA AMASIFUEN

Asesor:

Ing, Marlon Roger Dávila Picón

Anteproyecto de Tesis presentado para optar el título profesional de

Ingeniero de Sistemas

Iquitos – Perú

2013

ÍNDICE GENERAL

DATOS GENERALES

Título 05

Área y Línea de investigación 05

Área 05

Línea 05

Autor 05

Colaboradores 05

Personas Naturales 05

Duración estimada de ejecución 05

Fuentes de Financiamiento 05

Recursos propios 05

Recursos externos en gestión 05

Presupuesto estimado: S/. (nuevos soles) 05

PLAN DE INVESTIGACIÓN

Título 06

Planteamiento del problema 06

Descripción del Problema 06

Formulación del Problema 09

Objetivos 09

Objetivo General 09

Objetivos específicos 09

Justificación de la Investigación 09

Marco teórico referencial 10

Antecedentes del estudio 10

La Crisis del Software 10

La necesidad de la Ingeniería de Software 12

La Ingeniería de Requisitos 12

Bases teóricas 15

Ingeniería de Requisitos: 15

Las dimensiones de la ingeniería de requisitos 17

El concepto de requisito 18

Las dimensiones de los Requisitos 18

Los requisitos como restricciones 21

Propiedades deseables de los requisitos 22

Hipótesis 29

Variables 29

Aspectos Metodológicos 29

Tipo de Investigación 29

Diseño de Investigación 29

Población y Muestra 29

Técnicas, instrumentos y procedimiento de recolección de datos 30

Aspecto Administrativo 30

Cronograma 30

Recursos 31

Presupuesto 31

Bibliografía 32

ÍNDICE DE FIGURAS

Figura 01: Resultado del Informe GAO 14

Figura 02: Resultado del Informe CHAOS 14

Figura 03: La ingeniería de Requisitos en el Ciclo de Vida de Desarrollo de Software 17

Figura 04: Dimensiones de la Ingeniería de Requisitos 18

Figura 05: Dimensiones de los Requisitos 20

Figura 06: Los Requisitos como restricciones 23

Figura 07: La Ingeniería de Requisitos como un proceso de comunicación 24

Figura 08: Requisitos Innecesarios 25

Figura 09: Requisitos incompletos 26

Figura 10: Requisitos Inconsistentes 28

“Desarrollo De Un Entorno Metodológico De Ingeniería De Requisitos Para Microempresas Desarrolladoras De Software

DATOS GENERALES

Título

“Desarrollo De Un Entorno Metodológico De Ingeniería De Requisitos Para Microempresas Desarrolladoras De Software”

Área y Línea de investigación

Área

Desarrollo

Línea

Ingeniería de Software

Autor

Bach. Erick Giovanni Borra

Colaboradores

Personas Naturales

Ing. Marlon Dávila Picón

Duración estimada de ejecución

6 meses.

Fuentes de Financiamiento

Recursos propios

Equipos de cómputo

Recursos externos en gestión

n/a

Presupuesto estimado: S/. (nuevos soles)

S/. 7000.00

PLAN DE INVESTIGACIÓN

Título

Desarrollo De Un Entorno Metodológico De Ingeniería De Requisitos Para empresas Desarrolladoras De Software en la ciudad

Planteamiento del problema

Descripción del Problema

La ingeniería es el conjunto de conocimientos y técnicas científicas aplicadas a la creación, perfeccionamiento e implementación de estructuras (tanto físicas como teóricas) para la resolución de problemas que afectan la actividad cotidiana de la sociedad.

El desarrollo de los Sistemas de información computacional (como cualquier otra obra de ingeniería) requiere una serie de etapas para su correcta implementación, este proceso recibe el nombre de “Ingeniería de Software”; el mismo que enmarca una serie de pasos que tienen por objetivo que el proyecto de software sea eficaz; esto quiere decir que se cumpla con los plazos, el presupuesto, la calidad y las especificaciones esperadas por el usuario final; en este marco la ingeniería de Requisitos es una de las etapas más importante, esto debido a que quizá la parte más complicada de la construcción de un sistema es precisamente definir “que se va construir”, nótese en este punto que en caso de que se especifiquen mal los requisitos del software, estos errores tendrán un “efecto dominó” en los demás pasos subsecuentes del proceso, lo que dará como resultado serias dificultades en el proyecto que van desde el aplazamiento del tiempo de entrega del proyecto, hasta la reestructuración total/parcial del sistema y en algunos casos la cancelación del mismo, incurriéndose con esto en costos para la organización y toma de decisiones erróneas por parte del personal del nivel estratégico de la empresa.

El problema principal de los proyectos de software consiste en que lo que el usuario espera por lo general no coincide con lo que el equipo de desarrollo le presenta al concluir el proyecto; estas diferencias acarrea que se realicen cambios no previstos en el sistema; estos cambios requieren por lo general que el periodo estimado del proyecto se amplíe y con ellos los costos del mismo; por otro lado incluso con este periodo adicional no se garantiza que la totalidad de los requisitos del usuario sean satisfechos por el sistema; además debido a que los “nuevos requisitos” identificados en la etapa de validación no formaban parte de los requisitos originales es posible que el código fuente del sistema no se adapte a ellos incurriendo en costos aun mayores por la reestructuración parcial/total del código o en su defecto la realización de los cambios en forma incongruente con los esquemas iniciales acarreando con ello un código poco escalabre, legible y flexible.

Este conjunto de problemas fue conocido como “la crisis del software”, término que fue acuñado en 1968 en la conferencia organizada por la OTAN sobre desarrollo de software; desde ese tiempo y durante algo más de 4 décadas se realizaron estudios para determinar el origen de la crisis, la misma que incluso en nuestros días sigue aquejando a la mayoría de los proyectos de software a nivel mundial.

Inicialmente la mayoría de investigadores creían que el problema radicaba en la forma como se venía desarrollando los sistemas; esto debido a que en aquel tiempo no se contaba con metodologías, estándares o paradigmas de desarrollo formalmente definidos.

Para tratar de mitigar esta crisis surgieron diferentes metodologías y paradigmas para el desarrollo ordenado y sistémico de sistemas de información computacional; los primeros estándares de desarrollo hacían mucho hincapié en la documentación de los modelos abstractos que se utilizarían como base en la construcción del sistema; sin embargo al presentar los proyectos los usuarios finales tenían los mismos problemas de calidad del sistema y el cumplimiento de los requisitos.

Basado en estas experiencias se tomó como axioma que la las necesidades de los usuarios están en constante cambio y evolución por lo cual resultaba inadecuado (bajo este enfoque) consumir una gran cantidad del tiempo del proyecto en la preparación de la documentación de desarrollo pues al finalizar el proyecto (algunos meses después) dicha información sería obsoleta.

Para resolver este problema surgieron las “metodologías ágiles”; el espíritu de este tipo de metodologías es el cambio continuo; es decir, estas metodologías postulaban la idea de que al ser las necesidades de los usuarios tan volátiles y variables (como se creía) resulta innecesario realizar un amplio proceso de preparación y modelado del sistema; pues al concluir el proyecto toda esa información estaría desfasada por los nuevos requisitos; en cambio estas metodologías (de la mano con los paradigmas más recientes como la “Programación Orientada a Objetos”) animaba al equipo de desarrollo a construir sistema fácilmente modificables y a realizar revisiones periódicas y continuas del proyecto por parte de los usuarios.

Si bien es cierto estas metodologías lograron que la calidad de los proyectos de software fuera en aumento; en términos generales aun se contaba con el problema inicial, es decir; aun se tenía altos costos por modificación del proyecto ya sea en tiempo como en costos; y aun así el equipo de desarrollo aun no tenía realmente claro lo que el usuario requería.

Durante la última década un grupo de investigadores (cada vez más, en aumento) han prestado más atención a la primera etapa del proyecto de software, la ingeniería de requisitos (también llamado Elicitación de requisitos) haciendo hincapié en que es necesario conocer en detalle lo que el usuario va necesitar para poder

...