Propuesta de Modelo para el desarrollo de aplicaciones ...repository.udistrital.edu.co/bitstream/11349/7576/1/ReyesMozoJoséVicente2018.pdfPropuesta de Modelo para el desarrollo de

Propuesta de Modelo para el desarrollo de

aplicaciones “TIC” para la Facultad Tecnológica de

la Universidad Distrital Francisco José de Caldas

Autor

José Vicente Reyes Mozo

Tutor

PhD Giovanny Mauricio Tarazona Bermúdez

Universidad Distrital Francisco José De Caldas

Maestría en Ingeniería Industrial

Énfasis en Automática e Informática Industrial

Bogotá, Colombia

diciembre de 2017

Propuesta de Modelo para el desarrollo de aplicaciones “TIC” para la Facultad Tecnológica de la

Universidad Distrital Francisco José de Caldas

Página | 2

TABLA DE CONTENIDO

LISTA DE FIGURAS .......................................................................................................... 6

LISTA DE TABLAS ............................................................................................................ 8

LISTA DE GRAFICAS ........................................................................................................ 9

PREFACIO ...................................................................................................................... 10

DEDICATORIAS Y AGRADECIMIENTOS ....................................................................... 11

RESUMEN ....................................................................................................................... 12

SUMARY ......................................................................................................................... 13

ABREVIACIONES, SÍMBOLOS Y OTROS ...................................................................... 14

INTRODUCCIÓN ............................................................................................................. 15

1. PROBLEMA DE INVESTIGACIÓN ........................................................................... 17

1.1. PLANTEAMIENTO DEL PROBLEMA ................................................................... 17

1.2. FORMULACION DEL PROBLEMA ....................................................................... 18

1.3. OBJETIVOS .......................................................................................................... 19

1.3.1 Objetivo general ................................................................................................ 19

1.3.2 Objetivos específicos ......................................................................................... 19

1.4. JUSTIFICACION ................................................................................................... 19

1.5. HIPÓTESIS ........................................................................................................... 21

1.6. LIMITACIONES ..................................................................................................... 21

1.7. METODOLOGÍA PROPUESTA ............................................................................. 21

1.7.1 Fase de Análisis ................................................................................................ 22

1.7.2 Fase de caracterización ..................................................................................... 22

1.7.3 Fase de diseño .................................................................................................. 22

1.7.4 Fase de validación ............................................................................................. 22

1.7.5 Procedimiento metodológico .............................................................................. 23



Página | 3

2. MARCO DE REFERENCIA ...................................................................................... 24

2.1. MARCO TEÓRICO................................................................................................ 24

2.1.1 Software ............................................................................................................ 25

2.1.2 Ciclo de vida del Software ................................................................................. 26

2.1.2.1. Ciclo de vida lineal ......................................................................................... 27

2.1.2.2. Ciclo de vida en cascada puro ....................................................................... 27

2.1.2.3. Ciclo de vida en V .......................................................................................... 28

2.1.2.4. Ciclo de vida tipo Sashimi .............................................................................. 29

2.1.2.5. Ciclo de vida en cascada con sub proyectos .................................................. 30

2.1.2.6. Ciclo de vida iterativo ..................................................................................... 30

2.1.2.7. Ciclo de vida por prototipos. ........................................................................... 31

2.1.2.8. Ciclo de vida Evolutivo ................................................................................... 32

2.1.2.9. Ciclo de vida Incremental ............................................................................... 32

2.1.2.10. Ciclo de vida en espiral .................................................................................. 33

2.1.2.11. Ciclo de vida orientado a objetos ................................................................... 34

2.1.3 Ingeniería de Software ....................................................................................... 35

2.1.4 Ingeniería de Requerimientos ............................................................................ 36

2.1.4.1. Determinación de los Requerimientos de Calidad del Producto Software Basados

en Normas Internacionales .............................................................................................. 36

2.1.4.2. Clasificaciones de tipos de requisitos para la mejora del proceso de desarrollo del

software ........................................................................................................................... 36

2.1.5 Metodología de desarrollo de Software. ............................................................. 37

2.2. MARCO CONCEPTUAL ....................................................................................... 38

2.2.1. Aplicación de software ........................................................................................... 38

2.2.2. Traceability ............................................................................................................ 38

2.2.3. CMMI ..................................................................................................................... 38



Página | 4

2.2.4. Mantenimiento de Software. ................................................................................... 39

2.2.5 Estándar ISO/IEC 12207 (Singh, 1996a) ........................................................... 39

3. ANALISIS DE REQUERIMIENTOS PARA EL DESARROLLO DEL MODELO ......... 40

3.1. MODELOS DE DESARROLLO DE SOFTWARE ...................................................... 40

3.1.1. Un Modelo para el Desarrollo Cooperativo de Software ......................................... 40

3.1.2. Propuesta de metodología de desarrollo de software para objetos virtuales de

aprendizaje -MESOVA ..................................................................................................... 43

3.1.3. Un modelo de proceso de desarrollo de software guiado por traceability ............... 44

3.1.4. Modelo para el desarrollo de software basado en competencias. MODESEC ....... 45

3.1.5. Metodología para el desarrollo de software multimedia educativo MEDESME ....... 46

3.1.6. Metodología desarrollo de software para pymes de retail ...................................... 47

3.1.8 Otras metodologías de desarrollo de software ................................................... 50

3.2. Metodologías tradicionales. ................................................................................... 51

3.2.1 Metodología XP ................................................................................................. 51

3.3. ANALISIS DE LA INFORMACION ............................................................................ 52

3.3.1 Análisis teniendo en cuenta las etapas involucradas ......................................... 53

3.3.2 Análisis teniendo en cuenta el conocimiento requerido ...................................... 55

3.3.3 Análisis teniendo en cuenta la especialidad requerida en cada etapa................ 56

4. MODELO PARA EL DESARROLLO DE APLICACIONES ........................................ 59

4.1. INTRODUCCION ...................................................................................................... 59

4.2. MODELO PROPUESTO ....................................................................................... 59

4.2.1. Etapa de idear ................................................................................................... 62

4.2.1.1. Planear .......................................................................................................... 63

4.2.1.2. Necesidad ...................................................................................................... 65

4.2.1.3. Actividad ........................................................................................................ 66



Página | 5

4.2.1.4. Tarea ............................................................................................................. 67

4.2.1.5. Dinámica de la etapa 1 ................................................................................... 68

4.2.2. Etapa de requerir ............................................................................................... 69

4.2.2.1. Origen de los requerimientos ......................................................................... 70

4.2.2.2. Tipos de Requerimientos ............................................................................... 72

4.2.2.3. Importancia de recopilar requisitos ................................................................. 73

4.2.2.4. Matriz de requisitos ........................................................................................ 74

4.2.3. Etapa de modelar .............................................................................................. 75

4.2.3.1. Clasificar ........................................................................................................ 76

4.2.3.2. Relacionar ...................................................................................................... 76

4.2.3.3. Diseñar .......................................................................................................... 76

4.2.4. Etapa de desarrollar .......................................................................................... 77

4.2.5. Etapa de pruebas .............................................................................................. 78

5. EVALUACION Y VALIDACION DEL MODELO ......................................................... 80

5.1. POBLACIÓN OBJETIVO ....................................................................................... 80

5.2. APLICACIÓN DEL MODELO ................................................................................ 80

5.3. ANALISIS DE RESULTADOS ............................................................................... 80

CONCLUSIONES ............................................................................................................ 88

MATRÍZ DE CONTRASTACIÓN DE OBJETIVOS ........................................................... 89

RECOMENDACIONES Y LÍNEAS FUTURAS DE INVESTIGACIÓN. .............................. 90

REFERENCIAS ............................................................................................................... 91

ANEXOS .......................................................................................................................... 96

Anexo 1. Modelo de la encuesta aplicada ........................................................................ 96



Página | 6

LISTA DE FIGURAS

Figura 1. Diagrama de desarrollo de la Investigación. Fuente Autor 22

Figura 2. Curvas de falla del software. Adaptado de: (Pressman, 2010) 26

Figura 3. Ciclo de vida lineal. Adaptado de (Pressman, 2010) 27

Figuran 4. Ciclo de vida en cascada. Adaptado de: (Cantone, 2005) 28

Figura 5. Ciclo de vida en V. Tomado de: (Pressman, 2010) 29

Figura 6. Ciclo de vida tipo Sashimi. Adaptado de: (Cantone, 2005) 29

Figura 7. Ciclo de vida en cascada con sub proyectos. Tomado de: (Cantone, 2005) 30

Figura 8. Ciclo de vida iterativo. Tomado de: (Pressman, 2010) 31

Figura 9. Ciclo de vida por prototipos (Cantone, 2005) 31

Figura 10. Ciclo de vida evolutivo. (Pressman, 2010) 32

Figura 11. Ciclo de vida incremental. (Cantone, 2005) 33

Figura 12. Ciclo de vida en espiral. (Boehm, 2000) 34

Figura 13. Ciclo de vida orientado a objetos (Cantone, 2005) 35

Figura 14. Modelo de desarrollo cooperativo de software. Tomado de: (Jiménez & Abarca,

n.d.) 42

Figura 15. Fases de la metodología MESOVA. Adaptado de: (Castrillón, 2011) 43

Figura 16. Proceso de desarrollo de Software. Adaptado de: (Vanzetti, 2006) 45

Figura 17. Modelo para el desarrollo de software educativo basado en competencias.

Tomado de: (Toscano & Caro, 2015) 46

Figura 18. Procedimiento general de la metodología. Tomado de: (Colella, 2009) 48

Figura 19. Modelo propuesto. Tomado de: (Holzer & Ondrus, 2009) 49

Figura 20. Esquema general del modelo propuesto. Fuente: autor 60

Figura 21. Modelo general ampliado. Fuente: autor 61

Figura 22. Etapa de concepción de la idea. Fuente: autor 62

Figura 23. Concepción de la idea. Fuente: autor 63

Figura 24. Tipos de necesidad. Fuente: autor 66

Figura 25. La Necesidad. Fuente: autor 66

Figura 26. Determinación de actividad y acción. Fuente: autor 67

Figura 27. Estados de una tarea. Fuente: autor 68

Figura 28. Etapa de requerimientos. Fuente: autor 70



Página | 7

Figura 29. Sentidos de los requerimientos. Fuente: autor 71

Figura 30. Tipos de recursos. Fuente: autor 73

Figura 31. Etapa de modelar. Fuente: autor 75

Figura 32. Etapa de desarrollar. Fuente: autor 77

Figura 33. Etapa de pruebas. Fuente: autor 78



Página | 8

LISTA DE TABLAS

Tabla 1. Escala de niveles de valoración 53

Tabla 2. Análisis por etapas 54

Tabla 3. Ponderación por grado de conocimiento requerido 56

Tabla 4. Análisis por especialidad 57

Tabla 5. Roles de usuario 72

Tabla 6. Requisitos funcionales 72

Tabla 8. Matriz de requisitos 74

Tabla 9. Evaluación de calidad en cada etapa 81

Tabla 10. Evaluación del grado de implementación en cada etapa 82

Tabla 11. Valoración de cada etapa en cuenta a conocimiento requerido 83



Página | 9

LISTA DE GRAFICAS

Gráfica 1. Total, exportaciones de servicios de software y TI 21

Grafica 2. Grado de uso de las etapas 55

Grafica 3. Nivel de especialidad en las etapas 58

Grafica 4. Valoración de las etapas del modelo. 81

Gráfica 5. Evaluación de la calidad de cada etapa del modelo 82

Gráfica 6. Evaluación del grado de implementación en cada etapa 83

Gráfica 7. Valoración de cada etapa en cuenta a conocimiento requerido 84

Gráfica 8. Respuesta del seguimiento al modelo 84

Gráfica 9. Evaluación general del modelo 85

Grafica 10. Aporte al conocimiento 85

Grafica 11. Implementación en el contexto regional 86



Página | 10

PREFACIO

Actualmente con el uso de las tecnologías de la información y las comunicaciones y el uso

de los dispositivos móviles existentes, permite que la mayoría de las personas estén

conectadas y utilicen muchos los servicios y aplicaciones de diferentes propósitos que están

disponibles por estos medios, esto ha despertado el sentido por crear empresa o por aportar

con una solución que facilite o permita prestar un servicio; para la creación de este tipo de

aplicaciones o servicios que corren bajo estas plataformas, existen en el mercado diferentes

metodologías de desarrollo de software. Si tuvieras que desarrollar una aplicación de estas

una de muchas preguntas a resolver seria: ¿estarían en capacidad de entender y seguir

una metodología de desarrollo de software, sin tener la formación o conocimiento

suficientes?, se puede decir que algunos se valen de conocimientos o expertos amigos que

les pueden ayudar, otros tendrán el conocimiento suficiente, pero existen otros que quieren

realizar un proyecto en esta área y seguramente no lo pueden hacer.

Este documento presenta un modelo para el desarrollo de este tipo de aplicaciones, al final

no te tendrá un producto terminado, pero, si avanzaras en actividades que son de gran

interés para el desarrollo de un producto, esto sin la dirección de un experto que

seguramente deberías contratar; espero que le pueda beneficiar con respecto a lo que

realmente quiere; estoy seguro que le puede estar ayudando a resolver su problema.



Página | 11

DEDICATORIAS Y AGRADECIMIENTOS

A Dios por haberme dado la oportunidad de vivir la vida, compartir experiencias en la

enseñanza, el aprendizaje, y en la búsqueda de nuevas expectativas que ayuden a cambiar

el sentido de pensar y vivir de las demás personas; a mi esposa porque ha soportado las

diferentes vicisitudes que han surgido durante este y todos los momentos que hemos vivido

como pareja, a mis hijas Paola Andrea y Jenny Catalina, que viven con esperanza y amor

por la lucha y el quehacer de sus padres, esperan en la prosperidad como familia.

A mi tutor por dedicar tiempo valioso para colaborarnos, darnos ideas y exigirnos la

terminación de este proyecto como una etapa valiosa tanto intelectual como económica que

nos permite escalar profesionalmente; así como a la Doctora Luz Andrea por dedicarnos un

valioso tiempo para exigirnos y mostrarnos la verdadera ruta para poder entender los

ideales que de una u otra forma están plasmados en este documento.

A las personas que hicieron posible el desarrollo de este proyecto, a todos los que

estuvieron pendientes y aplaudieron este esfuerzo.



Página | 12

RESUMEN

El uso de las Tecnologías de Información y las Comunicaciones (TIC), el comercio

electrónico, y plataformas virtuales es cada vez mayor, según informe de competitividad;

en cuanto al consumo de aplicaciones un gran porcentaje de estos hace uso de redes

sociales, otro gran porcentaje de la población hace uso de sistemas de información,

actividades de entretenimiento y comercio electrónico, para la compra y venta de productos.

Esto ha hecho que el requerimiento e ideación sea cada vez mayor y con más frecuencias

persona quieran desarrollar aplicaciones que puedan o tengan la posibilidad de facilitar la

solución a una necesidad.

Aunque diversas metodologías para el desarrollo de software, hacer el seguimiento para el

desarrollo de su proyecto, requiere de tener conocimiento y en algunos casos experiencia

en el uso de estas metodologías y en desarrollo de proyectos de software; por lo tanto se

propone un modelo para el desarrollo aplicaciones en el área TIC, el cual está dirigido

inicialmente estudiantes de la Facultad Tecnológica de la Universidad Distrital Francisco

José De Caldas, que les ayude a orientar de una forma más precisa y adecuada en

concretar la idea, planear los requerimientos y diseñar un esquema de la aplicación.

Se hace el estudio de los diferentes modelos y metodologías de desarrollo de software y

finalmente se presenta la propuesta del modelo basado en las características e indicadores

antes identificados, el cual genere diferencia entre los existentes y permita a través de las

etapas y actividades propuestas. Con etapa de ideación, la cual permite y ayuda a la

recolección de información, y el proceso de requerimiento que son etapas importantes en

las metodologías para el desarrollo de software. Es una aproximación para las ideas de

emprendimiento y personas que no tengan los recursos o el conocimiento ideal en el

desarrollo de aplicaciones.

PALABRAS CLAVE

Desarrollo de aplicaciones, TIC, Modelo de desarrollo de software, Software, Etapas de

desarrollo.



Página | 13

SUMARY

The use of Information and Communication Technologies (ICT), electronic commerce, and

virtual platforms is growing, according to the competitiveness report; In terms of application

consumption, a large percentage of them use social networks, another large percentage of

the population makes use of information systems, entertainment activities and electronic

commerce, for the purchase and sale of products. This has made the requirement and

ideation is increasing and with more frequencies person want to develop applications that

can or have the possibility of facilitating the solution to a need.

Although different methodologies for software development, monitoring for the development

of your project requires knowledge and in some cases experience in the use of these

methodologies and in the development of software projects; therefore, a model for the

development of applications in the ICT area is proposed, which is initially aimed at students

of the Faculty of Technology of the Francisco José De Caldas District University, which helps

them to orient in a more precise and adequate way in specifying the idea, plan the

requirements and design an outline of the application.

The study of the different models and methodologies of software development is made and

finally the proposal of the model based on the characteristics and indicators identified above

is presented, which generates a difference between the existing ones and allows through

the proposed stages and activities. With the ideation stage, which allows and helps the

collection of information, and the requirement process, which are important stages in the

methodologies for software development. It is an approach for entrepreneurial ideas and

people who do not have the resources or ideal knowledge in the development of

applications.

KEYWORDS

Application development, ICT, Software development model, Software, development cycles.



Página | 14

ABREVIACIONES, SÍMBOLOS Y OTROS

TIC Tecnologías de la Información y las Comunicaciones

UDFJC Universidad Distrital Francisco José de Caldas

FT Facultad Tecnológica

MINTIC Ministerio de las Tecnologías de la Información y las Comunicaciones

SW Software

IEEE Institute of Electrical and Electronics Engineers

XP eXtreme Programing

RUP Rational Unified Process

ISO International Organization for Standardization

IEC International Electrotechnical Commission



Página | 15

INTRODUCCIÓN

El continuo avance de las Tecnologías de la Información y las Comunicaciones “TIC”, han

hecho que cada vez se usen más en diferentes quehaceres y áreas del conocimiento, ahora

es frecuente encontrar aplicaciones que ayudan a la toma de decisiones o en la solución

de un problema, así como para el avance y desarrollo social de una comunidad; (Mohd,

Maat, & Mat, 2014; Moraa & Gathege, 2013) gracias a que la transferencia de datos y la

interconexión de redes de comunicaciones es más económico y con medios que permiten

gran volumen y tráfico de información (Competitividad, 2014) Además, en la última década

el uso de las Tecnologías de Información y las Comunicaciones (TIC), el comercio

electrónico, y plataformas virtuales es cada vez mayor, según informe de competitividad

aproximadamente el 56% de los colombianos tienen internet; en cuanto al consumo de

aplicaciones un gran porcentaje de estos hace uso de redes sociales, otro gran porcentaje

de la población hace uso de sistemas de información, actividades de entretenimiento y

comercio electrónico, para la compra y venta de productos. Esto ha hecho que el

requerimiento e ideación de este tipo de herramientas sea cada vez mayor y con más

frecuencias persona quieran desarrollar aplicaciones que puedan o tengan la posibilidad de

facilitar la solución a una necesidad.

Sumado a esto, la política pública de emprendimiento ha hecho que Instituciones de

Educación Superior creen centros de emprendimiento y apoyen a sus estudiantes a través

de asignaturas o herramientas que permiten el auge de proyectos que generan innovación

y entre otros el desarrollo de aplicaciones TIC. La Universidad Distrital Francisco José de

Caldas, según acuerdo 038 del 28 de julio de 2015, cuenta con diferentes opciones de

grado, una de estas es el desarrollo de un proyecto de emprendimiento; para esto la

Facultad Tecnológica creo un centro de Emprendimiento que permite que estudiantes de

los diferentes programas de la facultad lo utilicen para presentar su proyecto de grado bajo

esta modalidad, dando posibilidad al desarrollo de aplicaciones de software.

Aunque existen diferentes metodologías para el desarrollo de software, ejemplo para

aplicaciones en la educación, en el sector financiero, industrial, o genéricas para el

proyectos de propósito específico de acuerdo a la necesidad del cliente, en donde hacer el

seguimiento para el desarrollo de su proyecto, requiere de tener conocimiento y en algunos



Página | 16

casos experiencia en el uso de estas metodologías y en desarrollo de proyectos de

software, debido a la diversidad y los requisitos que estas mimas tienen para el seguimiento

y control de un proyecto de software.

Teniendo en cuenta que existen persona que requieren hacer software, pero no tienen el

conocimiento o experiencia para desarrollar una aplicación, se propone un modelo para el

desarrollo aplicaciones en el área TIC, el cual está dirigido inicialmente estudiantes de la

Facultad Tecnológica de la Universidad Distrital Francisco José De Caldas, como prueba

piloto de dicha propuesta, y les ayude a orientar de una forma más precisa y adecuada en

concretar la idea, planear los requerimientos y diseñar un esquema de la aplicación y así

realizar su propias aplicaciones de software.

Para el desarrollo de la propuesta inicialmente se hace el estudio de los diferentes modelos

y metodologías de desarrollo de software, a través de actividades como recolectar

información, analizar e identificar características de cada metodología, y en una matriz

mostrar la caracterización de la información analizada; esto con el fin de especificar y

extraer las variables y parámetros característicos de cada una de estas; finalmente se hace

una propuesta del modelo basado en las características e indicadores antes identificados,

el cual haga la diferencia entre los existentes y permita a través de las etapas y actividades

propuestas, el producto final tenga una buena aproximación con respecto a las necesidades

para la cual se planteó.

El seguimiento y control del desarrollo de software es un proceso complejo, ya que cada

aplicación es diferente con relación a las existentes, este modelo tiene una etapa de

ideación, la cual permite y ayuda a la recolección de información, y al proceso de

requerimiento que son etapas importantes en las metodologías para el desarrollo de

software. Esta es una aproximación para las personas que tengan ideas de emprendimiento

y no tengan los recursos o el conocimiento ideal en el desarrollo de aplicaciones, y avance

en el proceso y no requiera de tanto personal especializado en software que normalmente

se requiere al aplicar los modelos tradicionales.



Página | 17

1. PROBLEMA DE INVESTIGACIÓN

1.1. PLANTEAMIENTO DEL PROBLEMA

En Colombia y especialmente en Bogotá ciudad capital, en donde se concentra gran

actividad económica, hay la posibilidad de generación de nuevas proyectos encaminados

al desarrollo de aplicaciones basadas en TIC, según (Díaz et al., 2016) el crecimiento es

más dinámico con respecto al resto del país, siendo mayor en los servicios personales,

sociales y comunales. Además, la política pública sobre el desarrollo de emprendimiento,

(Minncomercio, 2009) (Congreso, 2006) da la posibilidad que cualquier persona pueda

desarrollar un proyecto de software, sin necesidad de ser profesional en el área o tener

experiencia en el desarrollo de aplicaciones de software. Es así que Instituciones de

Educación Superior están incorporando en los currículos el emprendimiento. (UPTC, 2007)

(Unitecnológica, 2009) La universidad Distrital Francisco José de caldas según acuerdo 038

del 28 de julio de 2015, (Acuerdo, 2015) existen diferentes opciones con las cuelas los

estudiantes pueden optar.

El proceso de elaboración de una aplicación requiere de varias actividades, recursos y

tiempo, para lo cual es necesario tener conocimiento de cómo, cuanto y que tiempo puede

tomar del desarrollo de una actividad, así como poder determinar la prioridad existente entre

las diferentes actividades. Actualmente existen diferentes modelo y metodólogas de

desarrollo de software que agrupan actividades a desarrollar, y a través de diferentes

etapas, permite y facilita el desarrollo de software; muchas de esta metodologías de

desarrollo fueron creadas por empresas de desarrollo de software o para empresas de este

tipo, exigiendo en su mayoría que las personas tengan un amplio conocimiento en

desarrollo de software o en el área de sistemas y computación, como es el caso de

ingenieros o analistas de sistemas.

En la metodología de diseño, desarrollo y evaluación de software educativo, (Cataldi 2000)

propone diferentes etapas, las cuales involucran el componente pedagógico como aspecto

importante en el desarrollo del producto; aunque es una propuesta a nivel interdisciplinario,

estas etapas pueden confundir, además de que se debe tener conocimiento en didáctica y

pedagogía, para el proyecto de software educativo. Es importante resaltar que además



Página | 18

aparece un actor importante que es el docente, el cual ejerce un rol importante en este tipo

de software. Finalmente se puede decir que este tipo de metodología requiere de un

personal especializado para poder desarrollar una aplicación, y que está dirigida a una

población específica, además de los requerimientos propiamente dichos.

El modelo de emprendimiento para el desarrollo de productos en el área de TIC,

desarrollado en 2013 por Parquesoft Manizales, por solicitud de MINTIC, (Hugo, González,

David, & Castellanos, n.d.) el cual se creó con el fin de apoyar proyectos del área de TIC,

así como las metodologías y modelo de desarrollo de producto en TIC presentadas por

Kimball, Angélica de Antonio, Jaime, Pressman y Sommerville, y otros, fueron diseñadas

para orientar el desarrollo de producto, las cuales requieren de un conocimiento

especializado por parte de los desarrolladores.

Teniendo en cuenta la situación presentada anteriormente, se propone un modelo de

desarrollo de software como herramienta primaria para estudiantes que elijan como

desarrollo de proyecto de grado la opción de emprendimiento, y que necesiten de una guía

que los oriente y les permita cumplir con los objetivos propuestos en el mejor tiempo

Teniendo en cuenta la diversidad de oferta académica en los niveles de pregrado por ciclos

de la Facultad Tecnológica de la Universidad, en donde el carácter de formación es

tecnológico, un estudiante puede optar por desarrollar un producto en el área de TIC.

Ante esta situación, se hace necesario hacer estudios y generar un modelo que pueda

acompañar a los estudiantes y personas que quieren realizar aplicaciones en área TIC en

donde se incluyen temas de análisis de necesidad, requisitos necesarios, tanto en hardware

como en software y otros aspectos que son importantes para el desarrollo de un proyecto.

1.2. FORMULACION DEL PROBLEMA

¿Cómo desarrollar una aplicación a través de un modelo apropiado, sin conocer ni tener

experiencia en esto?



Página | 19

1.3. OBJETIVOS

1.3.1 Objetivo general

Proponer un modelo para el desarrollo aplicaciones en el área de TIC, dirigido a estudiantes

de la Facultad Tecnológica de la Universidad Distrital Francisco José De Caldas.

1.3.2 Objetivos específicos

Analizar modelos y metodologías de desarrollo de aplicaciones orientadas al área TIC,

existentes actualmente.

Caracterizar las variables que pueden intervenir en el proceso de desarrollo de

aplicaciones orientado al área de TIC.

Desarrollar el modelo propuesto, a través de la metodología utilizada para tal fin.

Validar el modelo a través de expertos en el área de TIC

1.4. JUSTIFICACION

El mercado de las aplicaciones en el área de TIC, en esta década tiene un gran auge, ya

que el uso de los sistemas de información en la dirección de las empresas es cada vez más

útil, permitiendo y facilitando a los directivos tomar decisiones de forma rápida y acertada

sobre los posibles cambios y expectativas que se pueden presentar (Cámara de Comercio

de Bogotá, 2015). Además el avance tecnológico y el uso de software para la simulación y

predicción de posibles eventos, sumado a esto actualmente el comercio electrónico

(Competitividad, 2014) (MinTIC, 2017; MintTIC, 2016), ha permitido que las empresas e

industrias utilicen estos recursos con mayor frecuencia y de forma más productiva.

En el acuerdo 038 del 28 de julio de 2015 (Acuerdo, 2015), se establecieron las

modalidades de opción de grado de los estudiantes de pregrado de la Universidad Distrital;

teniendo en cuenta las diferentes opciones de grado de un estudiantes, ellos pueden optar

por desarrollar aplicaciones TIC, sin tener como base de formación el área citada;

adicionalmente desde los diferentes grupos de investigación y a través de los semilleros de

investigación también se crean proyectos para los cual les permitiría y facilitaría el trabajo

en el desarrollo de una aplicación.



Página | 20

La Universidad Distrital a través de la Unidad de extensión se ha establecido convenios,

uno de ellos se hizo como centro de desarrollo tecnológico, en donde acudieron además de

otras áreas, emprendedores del área TIC, con necesidades importantes para el desarrollo

de aplicaciones TIC. También personas del sector correspondiente a la localidad de Ciudad

Bolívar, pueden tener la necesidad de desarrollar un producto del área buscando a la

Facultad Tecnológica que es uno de los centros de formación TI en la localidad.

Adicionalmente, el desarrollo de software se hace una vez analizado los datos y variables

que se tienen en cuenta en el proyecto; hacer un modelo a la medida permite evaluar los

proyectos de acuerdo a los aspectos que tenemos aquí en nuestra región. Al desarrollar un

proyecto como estos permite que el flujo dentro del centro de emprendimiento tenga mayor

rapidez y además facilite los procesos que se llevan a cabo dentro del centro de

emprendimiento.

Según el informe de la Superintendencia de Sociedades en cuanto a desempeño del sector

de software durante los años 2012 y 2014, el mercado de software y de Tecnologías de

Información, creció aproximadamente cinco veces, así como las exportaciones de los

mismos; adicionalmente en el mismo informe se manifiesta que empresas cuya actividad

registrada no es del área TIC, se están dedicando al desarrollo de productos TIC; en la

gráfica que se muestra a continuación se puede apreciar el crecimiento del Software y TI,

así como las exportaciones del mismo; dejando claro el incremento por desarrollo de

aplicaciones de software; (Sociedades, 2015) esto se evidencia en el informe de Nacional

de Competitividad, en el grado de inclusión que Colombia ha tenido en el mundo con

respecto a las Tecnologías de la Información y las Comunicaciones. (Competitividad, 2014)



Página | 21

Gráfica 1. Total, exportaciones de servicios de software y TI

Fuente: DANE – Programa de Transformación Productiva- PTP. Cálculos Grupo Estudios

Económicos y Financieros

1.5. HIPÓTESIS

Un modelo para desarrollo de software con etapas tempranas de planeación, requerimiento

y diseño ayuda a estudiantes a generar software, sin tener amplio conocimiento en esta

área o acudir a expertos, incrementado el deseo por realizar aplicaciones TIC.

1.6. LIMITACIONES

El proyecto se desarrolla para la Facultad Tecnológica de la Universidad Distrital Francisco

José de Caldas, ubicada en la ciudad de Bogotá, y se tiene en cuenta el desarrollo de

proyecto en el área de TIC. Por lo tanto, se aplicará únicamente a la población inicialmente

plateada.

1.7. METODOLOGÍA PROPUESTA

La metodología a aplicar está basada en una investigación aplicada de tipo cuantitativo. El

método a utilizar va a ser una investigación teórica, con las fases que se muestran en la

figuran 1, en la cual las actividades resaltadas en el recuadro son las de mayor importancia

2008 2009 2010 2011 2012 2013 2014

Total Exportaciones 37,626 32,846 39,713 56,915 60,125 58,824 54,795

Software & TI 69,37 69,02 97,78 129,12 167,85 223,48 216,93

0

50

100

150

200

250

0,000

10,000

20,000

30,000

40,000

50,000

60,000

70,000

Mill

on

es d

e d

óla

res

Mill

on

es d

e d

óla

res

FOB



Página | 22

en el desarrollo de la investigación; esto permitirá que el producto final tenga una

aproximación alta con respecto a las necesidades para la cual se planteó la Investigación.

Figura 1. Diagrama de desarrollo de la Investigación. Fuente Autor

Las actividades a nivel más específico para realizar el proceso investigativo serán las

siguientes:

1.7.1 Fase de Análisis

Recolectar información correspondiente a modelos de desarrollo de aplicaciones

basados en TIC.

Identificar características de los modelos recolectados

Desarrollar una matriz de caracterización

1.7.2 Fase de caracterización

Identificar las características e indicadores de mayor relevancia en cada uno de los

modelos identificados, para la construcción del modelo.

Hacer una ponderación del peso y relevancia de las características e indicadores.

1.7.3 Fase de diseño

Desarrollar el modelo propuesto, basado en las características e indicadores antes

identificados.

1.7.4 Fase de validación

Hacer simulación de pruebas con datos de funcionamiento de un centro de

emprendimientos.

Realizar los ajustes correspondientes, luego de las diferentes pruebas aplicadas al

modelo.

InvestigaciónAnálisis de

InformaciónDiseño

propuestoDesarrollo Pruebas Distribución



Página | 23

1.7.5 Procedimiento metodológico

Para el desarrollo de la investigación se realiza a través de cada una de las fases

planteadas en la metodología así:

Fase I. Busque de todo tipo de material bibliográfico a través de referentes internacionales

y base de datos, para realizar revisión de cada uno de estos, con el fin de identificar

aspectos y características diferenciadoras existentes entre los diferentes modelos de

desarrollo de software; para lo cual se generará una matriz resumen en donde muestran

ventajas y desventajas, además de elementos propios de cada metodología.

Fase II. Se parte de la matriz generada en la fase anterior y se identificaran los aspectos

relevantes de cada modelo y se ponderaran a fin de determinar el grado de incidencia que

puede tener en el modelo a proponer, teniendo en cuenta aspectos de la población objetivo.

Fase III. De acuerdo con el análisis anterior se procede a formular un modelo de desarrollo

de software teniendo en cuenta la incidencia encontrada en el respectivo estudio,

relacionando las variables en cada una de las etapas del modelo.

Fase IV Una vez desarrollado el modelo propuesto se procede a realizar pruebas,

permitiendo revisar cada una de las actividades y etapas propuestas en el modelo, de tal

forma que permitan identificar y mejorar el proceso de desarrollo de software, aportando

aspectos a tener en cuenta en el modelo. Para la validación se tomara un grupo de

estudiantes de primero y segundo semestre de la facultad tecnológica de la Universidad

Distrital, en donde se les aplicara el modelo para el desarrollo de un proyecto de clase, el

grupo se dividirá y una parte se aplica el modelo y la otra lo desarrollara con conocimientos

propios o buscados autónomamente.



Página | 24

2. MARCO DE REFERENCIA

La ingeniería de software implica mucha labor de responsabilidad más que la aplicación del

conocimiento y técnicas para el desarrollo de un producto, puesto que un proceso de

software es una serie de actividades relacionadas que conduce a la elaboración de un

producto de software, estos incluyen la especificación, diseño e implementación, validación

y evaluación. (Ing sw Somerville) Generalmente, los procesos de desarrollo de software son

complejos y por lo tanto incluyen personal con capacidad de gestionar.

Para el desarrollo del proyecto se tienen en cuenta las siguientes teorías y conceptos los

cuales son fundamentales para conocer y entender la investigación que se desarrolló,

además de definir algunos conceptos y términos relacionados con el desarrollo de software

tal como el proceso de requerimientos, análisis, diseño y desarrollo de este tipo de

proyectos, así como fundamentos que su utilizaron en el desarrollo del proyecto.

2.1. MARCO TEÓRICO

Con la aparición de las computadoras se agilizaron muchos procesos, se avanzó en las

comunicaciones y permitió compartir recurso de forma virtual con diferentes usuarios en

cualquier lugar del mundo; pero detrás de todo esto estaba la programación de

computadores que inicialmente se hacía de forma empírica, pero al pasar el tiempo se

generaron nuevos lenguajes de programación y a raíz de esto nuevas técnicas; teniendo

en cuenta la diversidad de lenguajes de programación de elementos y actividades a

desarrollar en la elaboración de un proyecto de software, se generaron nuevos estándares,

métodos y metodologías de programación que permite guiar el desarrollo de software.

Desde ese entonces algunos analistas y expertos en desarrollo de software, se ha

preocupado por desarrollar modelo y metodologías para que a través de ellas puedan

realizar proyectos más confiables. Existen metodologías para el desarrollo de software,

como las de (Alpizar, García, & Arroyo, 2014; Castrillón, 2011; Cataldi, 2000; García P,

2009; Jiménez & Abarca, n.d.; Nader, 2014a; Pérez, 2015; Valenzuela, Pavlich-Mariscal, &



Página | 25

A, n.d.; Yolanda, 2013) entre otras, que fueron creadas para que personas con amplio

conocimiento en sistemas y computación, o arquitectura de software, se guíen para el

desarrollo de sus proyectos.

Algunas de las temáticas tratadas en las diferentes metodologías se definen a continuación,

con el fin de contextualizar al lector en temas específicos del análisis de requerimientos,

metodología y desarrollo de software en general.

2.1.1 Software

En informática es considerado uno de los pilares, también se le denomina la parte lógica de

la computadora; según la real academia española es un “conjunto de programas,

instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.” Según

NN es el elemento lógico y no físico, además de que no se desgasta y además de que no

es susceptible a los problemas ambientales.

Actualmente existen diferentes clasificaciones del software dependiendo del uso o tipo de

desarrollo para lo cual se construyó, encontramos además de la clasificación de acuerdo a

las licencias o la forma de comercializarlo, software contable, administrativo, financiero, de

gestión, herramientas de desarrollo, y herramientas CAD; que agilizan, facilitan y ayudan

en los procesos que desarrollan actualmente las personas.

Aunque el software no se desgasta, se deteriora debido a los diferentes cambios que se le

hacen durante los mantenimientos correctivos, o actualizaciones solicitadas o hechas por

los ingenieros; en la figura 2 se puede observar la curva real del software y la curva en el

cual se evidencia que en los cambios cuando hay un cambio la tasa de fallas es demasiado

alta, esto se debe a factores como la compatibilidad, portabilidad u otros efectos que no

están presentes en el diseño, que se pueden ver afectados desde el mismo hardware de la

maquina en donde esté instalado.



Página | 26

Figura 2. Curvas de falla del software. Adaptado de: (Pressman, 2010)

2.1.2 Ciclo de vida del Software

El proceso de desarrollo de software incluye etapas como análisis, diseño y desarrollo de

acuerdo al orden de tareas y actividades que se desarrollen, adicionalmente puede tener

sub etapas las cuales tienen un enlace y una retroalimentación, además están coordinadas

sistemáticamente. Según (Cantone, 2005) el desarrollo de un sistema de información está

compuesto básicamente por tres etapas, las cuales son, planeación, implementación y

puesta en producción, adicionalmente se pueden tener en cuenta el inicio y control de

producción como etapas adicionales; se puede definir un objetivo en cada etapa que lo

caracterizan. También se encuentran documentos como el caso de (Pressman, 2010) en el

cual habla del modelo general del proceso y básicamente expresa que la estructura general

para la ingeniería de software define cinco actividades estructurales: comunicación,

planeación, modelado, construcción y despliegue, con actividades sombrilla las cuales se

pueden ejecutar en cada una de las actividades desarrolladas.

Existen diferentes modelos del ciclo de vida que pueden ser utilizados para el desarrollo de

un proyecto o se tienen en cuenta para el uso dentro del diseño y construcción de una

Tasa de fallas incrementada debido a efectos colaterales

Tiempo

Ta

sa

de

fa

lla

s

Cambio

Curva real

Curva idealizada



Página | 27

metodología de desarrollo de software, la diferencia de un ciclo de vida se hace de acuerdo

a la visión del proyecto, la cual tiene un alcance que permite verificar hasta donde llega el

proyecto.

2.1.2.1. Ciclo de vida lineal

Se considera como el más sencillo de todos, descomponen las actividades en etapas

separados para ser realizadas linealmente o una a la vez y luego la otra, con este es difícil

dividir áreas y prever tiempos, las actividades de cada etapa deben ser independientes no

hay retroalimentación se debe conocer que va a ocurrir en cada etapa antes de iniciar.

Reduce la necesidad de requerir información del cliente.

Figura 3. Ciclo de vida lineal. Adaptado de (Pressman, 2010)

Unas de las ventajas que tiene es la sencillez de administración económica y de gestión,

usual en proyectos pequeños; y como desventaja es que no es apto para proyectos con

retroalimentación entre etapas.

2.1.2.2. Ciclo de vida en cascada puro

Propuesto por Winston Royce en 1990. También llamado ciclo de vida clásico, admite

iteraciones, y después de cada etapa hay una o varias revisiones para comprobar si puede

pasar a la siguiente, es un modelo rígido y con muchas restricciones

Comunicación Planeación Modelado Construcción Despliegue



Página | 28

Figuran 4. Ciclo de vida en cascada. Adaptado de: (Cantone, 2005)

Como ventajas esta la planificación sencilla, provee un producto con elevado grado de

calidad sin personal calificado, y la desventaja es contar con todos los requerimientos al

inicio del proyecto, por lo tanto, es difícil regresar a la etapa anterior. Adecuado para

proyecto en los que los requerimientos están al comienzo. Además, La necesidad de

conocer los requerimientos al principio del proyecto es primordial al elegir este ciclo de vida.

2.1.2.3. Ciclo de vida en V

Diseñado por Alan Davis, lo importante del modelo es que mientras se avanza hacia abajo

en la V del modelo, se puede ir visualizando las mejoras que se pueden encontrar a través

de las diferentes pruebas aplicadas, que hacen que el producto tenga una mejor calidad;

luego de crear la aplicación y al avanzar hacia arriba de la V, aplicando las diferentes

pruebas, se hace verificación y validación del producto, permitiendo un mejor desarrollo

para un producto final.

Las ventajas y desventajas que presenta este modelo son las mismas del anterior, con

controles cruzados para lograr una mayor corrección y mejor calidad del software. Sirve de

gran utilidad para la creación de aplicaciones simples, pero con fiabilidad alta.

Req. del Sistema

Req. del Software

Diseño preliminar del

Software

Análisis

Diseño de programa

Codificación

Prueba

Operaciones

Alcance el prototipo

Análisis del prototipo

Diseño del prototipo

Codificación del prototipo

Prueba del prototipo

Uso del prototipo



Página | 29

Figura 5. Ciclo de vida en V. Adaptado de: (Pressman, 2010)

2.1.2.4. Ciclo de vida tipo Sashimi

Parecido al ciclo de vida en cascada puro, pero con solapamiento de etapas con

retroalimentación implícitamente en el modelo

Figura 6. Ciclo de vida tipo Sashimi. Adaptado de: (Cantone, 2005)

Modelado de los

requerimientos

Diseño de la

arquitectura

Diseño de los

componentes

Generación de

código

Pruebas

unitarias

Pruebas de

integración

Pruebas del

sistema

Pruebas de

aceptación

Software

ejecutable

Concepto

Análisis

Diseño de arquitectura

Diseño detallado

Implementación

Debugging



Página | 30

Un de las ventajas de este ciclo de vida es la ganancia de calidad, pero con la desventaja

de solapamiento de etapas, ya que es difícil administrar el comienzo y final de cada etapa,

y problemas de comunicación si los hay. Es válido para la creación de aplicaciones que

comparten recursos con otras, el solapamiento de etapas puede ahorrar recursos.

2.1.2.5. Ciclo de vida en cascada con sub proyectos

Cada una de las cascadas se divide en sub etapas independientes que se pueden

desarrollar en paralelo o módulos independientes que luego se integran para formar un

proyecto general.

Figura 7. Ciclo de vida en cascada con sub proyectos. Adaptado de: (Cantone, 2005)

Su ventaja principal es que hay más personal trabajando simultáneamente en el proyecto,

y como desventaja tenemos la dependencia entre las sub etapas. Esta se puede utilizar en

cualquier proyecto, pero se deben tener en cuenta los tiempos de entrega.

2.1.2.6. Ciclo de vida iterativo

Este modelo busca reducir el riego que hay entre las necesidades del usuario y el producto

final producido en la etapa de requerimientos. Consiste en iterar las veces que sea

subproyecto 3

Análisis del

software

Diseño del

software

Codificación

Pruebas del

software subproyecto 2

Análisis del

software

Diseño del

software

Codificación

Pruebas del

software

Análisis del

sistema

Diseño del

sistema

Integración de

subsistemas

Pruebas del

sistema

subproyecto 1

Análisis del

software

Diseño del

software

Codificación

Pruebas del

software



Página | 31

necesario una o varias etapas al mismo tiempo haciendo una entrega al final de cada una,

para que el cliente puede evaluar hasta entregar un producto que satisface la necesidad

requerida inicialmente.

Figura 8. Ciclo de vida iterativo. Adaptado de: (Pressman, 2010)

Este tipo de modelos puede ser utilizado cuando el cliente no tiene claros los

requerimientos, y para aplicaciones medianas y grandes o para la migración de

aplicaciones.

2.1.2.7. Ciclo de vida por prototipos.

Los prototipos son utilizados con el propósito de evaluar la aplicación; este ciclo de vida es

utilizado cuando no se conoce los requerimientos o el proceso de desarrollo, para lo cual

se hace un prototipo

Figura 9. Ciclo de vida por prototipos. Adaptado de: (Cantone, 2005)

Comunicación Planeación Modelador Construcción Despliegue

Plan rápido

Modelado Diseño rápido

Comunicación

Construcción del

Prototipo

Despliegue Entrega y

Retroalimentación



Página | 32

Como ventaja es que es apto para proyectos que no se conoce las especificaciones o

tecnología a utilizar, y su desventaja es que es costoso y difícil administrar, puede ser

utilizado en el desarrollo de productos con innovaciones importantes, uso de tecnologías

nuevas o poco probadas.

2.1.2.8. Ciclo de vida Evolutivo

Similar al iterativo pero su ciclo lo cumple cuando se realizan en conjunto todas las etapas,

los requerimientos de usuario cambian continuamente, ya que estos están en constante

evolución o surgen nuevos requerimientos, en este modelo al finalizar una iteración se crea

un producto para que el cliente lo evalué, y aliviar la presión del mismo por el desarrollo del

producto, el producto finalmente evoluciona de acuerdo la cantidad de ciclos.

Figura 10. Ciclo de vida evolutivo. Adaptado de: (Pressman, 2010)

Este modelo suele ser utilizado cuando se desconocen los requerimientos iniciales y se

requiere avanzar en el desarrollo del proyecto.

2.1.2.9. Ciclo de vida Incremental

Es modelo se desarrolla incrementando las funcionalidades del programa, como aporte

importante es que el desarrollo se hace por módulos que cumplen su función determinada

esto hace que el proyecto incremente las funcionalidades; permite una mayor y mejor

participación del equipo de trabajo. Se aplica en cada ciclo una funcionalidad a la aplicación

con entregas al cliente antes de finalizar.

Comunicación

Despliegue Construcción

Modelado

Planeación

Incremento

obtenido



Página | 33

Figura 11. Ciclo de vida incremental. Adaptado de: (Cantone, 2005)

La ventaja del modelo es que tiene un menor riesgo construyendo sistemas pequeños, por

funcionalidades se pueden detectar mejor los requerimientos, y solo se elimina una iteración

en caso de la existencia de errores; no necesitan todos los requerimientos al inicio. Es útil

cuando se requiere de proyectos con entregas rápidas.

2.1.2.10. Ciclo de vida en espiral

Variación del modelo con prototipado, diseñado por Boehm en 1988; consiste en ciclos

repetitivos, toma aportes del ciclo de vida incremental y por prototipos, tiene sus riesgos

debido a la falta de requerimientos iniciales. Se obtienen prototipos sucesivos. Tiene cuatro

actividades importantes en las etapas: planificación (requerimientos), análisis de riesgos

(continua o no), implementación (prototipo), evaluación (cliente)

Análisis

Diseño

Codificación

Pruebas

1

Versión 1

Funcionalidad 1

Análisis

Diseño

Codificación

Pruebas

1 2

Versión 2

+Funcionalidad 2

Análisis

Diseño

Codificación

Pruebas

1 2 3

Versión 3

+Funcionalidad 3



Página | 34

Figura 12. Ciclo de vida en espiral. Adaptado de: (Boehm, 2000)

Como ventajas de este modelo es que inicia el proyecto con alto grado de incertidumbre,

bajo riesgo de retraso en caso de errores, y su desventaja es el costo de cada iteración.

Puede ser utilizado este modelo para grandes proyectos de una empresa.

2.1.2.11. Ciclo de vida orientado a objetos

Desarrollado en los 90, lo importante para este es que cada funcionalidad o requerimiento

es considerado un objeto

RISK ANALYSIS

RISK ANALYSIS

RISK ANALYSIS

RISK

ANALPROTOTYPE2

PROTOTYPE3

OPERATIONAL

PROTOTYPE

PROTO

TYPE1

CONCEPT OF

OPERATION

EMULATIONS

MODELS BENCHMARKS

ROTS PLAN

LYFE CYCLE

PLAN

INTEGRATIO

N AND TEST

PLAN

DEVELOPMENT

PLAN REQUIREMENTS

VALIDATION

SOFTWARE

RQTS

SOFTWARE

PRODUCT

DESIGN DESIGN VALIDATION

AND VERIFICATION

DETAILED

DESIGN

CODE

UNIT

TEST INTEGRA

TION AND

TEST ACCEPT-

ANCE TEST IMPLEMEN

TATION DEVELOP, VERIFY NEXT LEVEL PRODUCT

PLAN NEXT

PHASES

DETERMINE OBJECTIVES, ALTERNATIVES, CONSTRAINTS

EVALUATE ALTERNATIVES IDENTIFY, RESOLVE RISK

PROGRESS THROUGH STEPS

CUMMULATIVE

COST

COMMITMENT

PARTITION

REVIEW



Página | 35

Figura 13. Ciclo de vida orientado a objetos. Adaptado de: (Cantone, 2005)

Importante abstracción, reduce la complejidad del problema y permite el perfeccionamiento

del producto. Se puede utilizar independiente del lenguaje elegido, es muy versátil y más

completo con relación a los anteriores.

2.1.3 Ingeniería de Software

Según Ian Sommerville (Sommerville, 2011b) en su libro de Ingeniería de Software la

historia de la Ingeniería de software parte de: “El concepto “ingeniería de software” se

propuso originalmente en 1968, en una conferencia realizada para discutir lo que entonces

se llamaba la “crisis del software” (Naur y Randell, 1969). Se volvió claro que los enfoques

individuales al desarrollo de programas no escalaban hacia los grandes y complejos

sistemas de software. Éstos no eran confiables, costaban más de lo esperado y se

distribuían con demora”; adicional a esto “a lo largo de las décadas de 1970 y 1980 se

desarrolló una variedad de nuevas técnicas y métodos de ingeniería de software, tales

como la programación estructurada, el encubrimiento de información y el desarrollo

orientado a objetos. Se perfeccionaron herramientas y notaciones estándar y ahora se usan

de manera extensa”. (Sommerville, 2011a)

La ingeniería de software busca apoyar el desarrollo de software, utilizando técnicas de

análisis, diseño y desarrollo además es una disciplina que se interesa por aspectos de la

producción de software, desde las etapas iniciales hasta la fase de operación del mismo;

como aspecto importante se tiene algunos atributos esenciales en el desarrollo de software

Fases Planificación

del negocio

construcción

Liberación

Crecimiento

Planificación

del negocio

construcción

Liberación

Mejora 1

Planificación

del negocio

construcción

Liberación

Mejora 2

Madurez Períodos

Actividades Planificación Investigación Especificación Implementa. Revisión



Página | 36

como es el mantenimiento, la confiabilidad y seguridad, eficiencia y aceptabilidad que son

aspecto importantes que comprometen de primera mano al cliente para generarle un

producto que garantice su satisfacción. Actualmente existen diferentes tipos de aplicación,

de acuerdo a la necesidad del cliente, el área de desarrollo y los recursos tecnológicos

involucrados en el desarrollo e implementación.

2.1.4 Ingeniería de Requerimientos

Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer: el

servicio que ofrece y las restricciones en su operación. Tales requerimientos reflejan las

necesidades de los clientes por un sistema que atienda cierto propósito, como sería

controlar un dispositivo, colocar un pedido o buscar información. Al proceso de descubrir,

analizar, documentar y verificar estos servicios y restricciones se le llama ingeniería de

requerimientos (IR). (Sommerville, 2011a)

El término “requerimiento” no se usa de manera continua en la industria del software. En

algunos casos, un requerimiento es simplemente un enunciado abstracto de alto nivel en

un servicio que debe proporcionar un sistema, o bien, una restricción sobre un sistema. En

el otro extremo, consiste en una definición detallada y formal de una función del sistema.

2.1.4.1. Determinación de los Requerimientos de Calidad del Producto Software

Basados en Normas Internacionales. Este documento usa una técnica para la

determinación de requerimientos basado en la vista de usuarios y el punto de vista de los

desarrolladores; y tiene en cuenta el usuario como actor importante en la determinación de

requerimientos. Es un proyecto basado en la norma ISO/IEC 9126 y recomendaciones de

PMBOOK, (Project Management Institute, 2013) es utilizada en las primeras etapas de un

proyecto de software.

Descomponer el software en componentes ya que tiene varios componentes con

necesidades diferentes y depende de la función que realiza dentro del producto final. Se

puede utilizar una técnica WBS, practica recomendada por PMI.

2.1.4.2. Clasificaciones de tipos de requisitos para la mejora del proceso de

desarrollo del software. El objetivo de este documento es la mejora en el proceso de



Página | 37

desarrollo de ingeniería de software, se resalta en este documenta unas técnicas utilizadas

para la captura de requisitos, dentro de estas la tormenta de ideas que consiste en la

acumulación de ideas sin evaluar las mismas, ofrece una visión general de las necesidades

del sistema, pero sin ofrecer detalles concretos. También aparecen los mapas conceptuales

que tienen conceptos y relaciones entre estos, estos sirven para aclarar los conceptos

relacionados con el sistema a desarrollar ofreciendo una visión general de las necesidades

del sistema.

Definición de requisitos: es necesario elaborar un documento de requisitos en el cual se

definen las necesidades y objetivos del sistema, técnicas propuestas: se resalta el uso de

patrones en el cual se define los requisitos mediante el lenguaje natural, pero de manera

estructuradas. Una plantilla es una tabla con una serie de campos y una estructura definida.

Se puede generar un catálogo de clasificación de requisitos.

Validación de requisitos. Se valoran comprobando la veracidad, consistencia y completitud

de requisitos. Técnicas: resalta matrices de trazabilidad que consiste en marcar los

objetivos del sistema y chequearlos contra los requisitos del mismo; es necesario ir viendo

que objetivos cubre cada requisito para detectar inconsistencias.

2.1.5 Metodología de desarrollo de Software.

Cuando se desarrolla un producto en este caso una aplicación de software, generalmente

se hace a través de un modelo, método o metodología, siguiendo cada uno de sus pasos o

etapas que esta tiene; como la mayoría de estas están diseñadas para que el seguimiento

lo haga un analista, diseñador o desarrollador de software, no todos tendrían la capacidad

y conocimientos que algunas de estas metodologías requieren para su desarrollo. Cada vez

que se requiere realizar una aplicación de propósito específico se busca un modelo

aproximado o similar que pueda facilitar su desarrollo

Una metodología surge debido a la necesidad de un cliente, teniendo en cuenta que no

existe ninguna documentación que le permita a un cliente tratar sus requerimientos de

forma clara, por lo tanto, todo se hace en la marcha y con algún desconocimiento. Una

metodología según la real academia española, es “conjunto de métodos que se siguen en

una investigación científica o en una exposición doctrinal”, para el caso del desarrollo de



Página | 38

software se habla de elementos necesarios para poder administra, gestionar un proyecto

de software, lo cual se hace a través de módulos que generalmente se conocen como

etapas o fases que inician desde la necesidad hasta finalizar el proyecto.

Las metodologías de desarrollo de software se clasifican en: estructurada, en donde cada

función se descompone en módulos individuales con el objetivo de resolver problemas,

preferiblemente pequeños, y metodologías orientadas a objetos en las cuales se arman

módulos basados en componentes, en donde cada componente es independiente del otro,

esto facilita la reutilización.

2.2. MARCO CONCEPTUAL

Para el desarrollo de la investigación existe una variedad de conceptos y temas de gran

importancia para dar contexto al tema en estudio:

2.2.1. Aplicación de software

Según el diccionario de la Real Academia Española, es un programa preparado para una

utilización específica, como el pago de nóminas, el tratamiento de textos.

2.2.2. Traceability

Según Palo y otros (Palo, 2003; Ramesh & Jarke, 2001) un modelo de referencia de

traceability nos permite especificar requerimientos hacia adelante o hacia atrás

adicionalmente manifiesta que es una técnica para hacer relaciones entre los

requerimientos. En el modelo de traceability se muestra una relación entre los diferentes

requerimientos y la interconexión con diferentes preguntas que le permiten al diseñador de

sistemas de información el tipo de relación que hay en dicho requerimiento; también puede

ser un verbo que escribe el tipo de relación entre los dos requerimientos.

2.2.3. CMMI

Es un modelo de madurez de mejora de los proceso para el desarrollo de productos y

servicios, según (Chrissis, Konrad, & Shrum, 2009) las organizaciones se concentran en

tres dimensiones la cuales son: las personas, los métodos y los procedimientos, pero

también hay que explotar el modo de operación, los conocimientos y la comprensión de las



Página | 39

tendencias de las actividades; además (Mellon, 2010) CMMI proporciona la estructura

necesaria para crear modelos de la formación y los componentes de evaluación, y cubre

las actividades para desarrollar tanto de productos como de servicios así como su gestión.

Se incluyen diferentes actores para la adecuación utilización de este modelo; puede ser útil

para empresas grades que manejan diferentes procesos y requiere de un diseño y

desarrollo de sus procesos, el tiempo para ejecutar ese modelo puede ser amplio ya que

esta diseñados en niveles, que a su vez estos pueden estar subdivididos en subniveles.

2.2.4. Mantenimiento de Software.

Según la real academia española es un “conjunto de operaciones y cuidados necesarios

para que instalaciones, edificios, industrias, entre otros, puedan seguir funcionando

adecuadamente”, cuando se habla de mantenimiento de software se hace referencia a las

actualizaciones y modificaciones para mejorar o corregir algunos defectos que se pudieron

cometer o no se hicieron en el desarrollo, también puede ser por el cambio de alguna norma,

ley o reglamentación para la cual se debe hacer una adaptación del software a este tipo de

cambios. Generalmente el software está en constante mantenimiento por diferentes

circunstancias.

2.2.5 Estándar ISO/IEC 12207 (Singh, 1996a)

Este estándar provee una contextualización dirigido a la parte de software, sin embargo,

este estándar está dirigido para cualquier tipo de software grande o pequeño, simple o

complejo, puede ser usado para el desarrollo de prototipos. El estándar cumple el uso de

prerrequisitos como entrenamiento de personal, familiaridad con la organización,

familiaridad con el entorno de proyectos y entender el estand.



Página | 40

3. ANALISIS DE REQUERIMIENTOS PARA EL DESARROLLO DEL MODELO

Este capítulo se presentan los diferentes modelos y metodologías de desarrollo de software,

además de artículos y documentos relacionados con la investigación que se está

desarrollando; se hace una clasificación por modelos y metodologías, luego los demás

documentos, extrayendo lo más importante, así como las características que sirven para

clasificar y caracterizar como variables que van a incidir en la construcción del nuevo

modelo. Teniendo en cuenta que existen diferentes modelos los cuales pueden crearse

para un área específica, se tendrían que clasificar por áreas, lo cual ampliaría el estudio;

sin embargo, es de notar que lo que más se encuentran son modelos para el desarrollo de

software educativo y empresarial. En este documento solo se clasifican en modelos y

metodologías de desarrollo de software.

3.1. MODELOS DE DESARROLLO DE SOFTWARE

Para el desarrollo de software, específicamente existen diferentes modelos que ayudan y

facilitan las diferentes actividades y tareas que tiene un modelo y que generalmente son

agrupadas a través de etapas las cuales le permite tener una guía para el desarrollo e

implantación de su aplicación requerida. A continuación, se hace un estudio de algunos de

estos modelos que se utilizan actualmente en el mercado.

3.1.1. Un Modelo para el Desarrollo Cooperativo de Software

El modelo que proponen (Jiménez & Abarca, n.d.) para el desarrollo cooperativo de

Software, está desarrollado para hacer seguimiento de proyectos en el contexto de software

educativo; este proyecto se desarrolla el estudio a través de grupos de trabajo cooperativo;

según el estudio realizado dice que cobra mayor importancia en Europa.

Sin embargo, también es evidente que el desarrollo de software educativo, suele ser

costoso y complejo ya que implica la integración de diferentes profesionales, especialistas

en el área académica para el cual se desarrollara el software.

Para el desarrollo lo clasificaron en 3 líneas de investigación: la primera es la de análisis y

descripción del trabajo en grupo, en equipo o de forma cooperativa. La segunda está



Página | 41

orientada a la construcción de modelos basados en enfoque cooperativo. La tercera es la

construcción de entornos y herramientas groupware. Adicionalmente hacen una

clasificación para dar soporte al diseño y desarrollo del software en tres enfoques

alternativos, los cuales son: desarrollo ad hoc, uso de toolkits y uso de entornos integrados.

En la investigación que se realizó se presenta el análisis de tres propuestas diferentes las

cuales son:

Teoría de la coordinación. Sugieren un enfoque coordinado, combinando e integrando

disciplinas diversas como informática, psicología, y economía entre otras; describen

como se pueden coordinar las actividades, como los actores pueden trabajar juntos

armoniosamente, y de esto se logran identificar 4 componentes, los cuales son:

objetivos, actividades, actores e interdependencias.

Teoría de la Actividad. Las presentan como acciones o cadenas de acciones que a su

vez son operaciones. Asigna una condición primaria para cualquier actividad la cual es

la presencia de una necesidad; las actividades son realizadas como acciones

individuales o cooperativas.

Teoría de la acción. Maneja abstracciones relacionadas, que hace que el conjunto de

trabajo sea más accesible. Están basadas en conceptos de acción e interacción que

son llevadas a cabo por más de un interactuante.

El desarrollo clásico y cooperativo de software lo presentan como el tiempo para construir,

entregar, y hacer evolucionar un producto de software, desde la idea hasta el fin. El objetivo

es que el desarrollo del software sea confiable y eficiente. Además, lo definen como un

conjunto de etapas llevadas a cabo por el equipo de desarrollo, y manejan un conjunto de

diferentes elementos que son utilizados dentro del modelo, dentro de los cuales tenemos:

lugar de actividad, actividad, tarea, equipo multidisciplinario.

En este documento se resalta que un modelo de desarrollo de software, presenta etapas

comunes como definición desarrollo y mantenimiento, pero se enfatiza en el ¿Qué? que

corresponde a la definición, el ¿Cómo? que hace parte del desarrollo y el ¿Cambio? que

hace parte del mantenimiento continuo. La propuesta la fundamenta como un modelo de

tipo iterativo con un estilo de desarrollo recursivo.



Página | 42

Lo conciben como un modelo que determina una trayectoria de actividades en el tiempo,

este modelo se presenta en la figura 14.

Figura 14. Modelo de desarrollo cooperativo de software. Adaptado de: (Jiménez & Abarca, n.d.)

Este modelo muestra relaciones entre elementos que participan en un lugar de actividad, y

se basan en conceptos como: acción, equipo multidisciplinario, etapa, recurso, repositorio

y las relaciones existentes entre ellos.

La clave de este modelo es la comunicación entre los miembros del equipo, por lo tanto,

debe haber un enlace entre ellos (a través de diferentes medios de comunicación). Es

necesario administrar y hacer seguimiento de las acciones del grupo a través de

responsabilidades, control y monitores, también es importante las herramientas que se usan

para el desarrollo de las diferentes acciones.

Actúa en

Transiciones

Llevadas a cabo en

Memoria de

Actividad

Mecanismos de Coordinación,

comunicación y Herramientas

Descripción de Etapas asociadas a cada tipo de lugar

Equipo Multidisciplinario

Es p

art

e d

e

Es p

art

e d

e

Es p

art

e d

e

Resultad

o

¿S

iguie

nte

?

Sig

uie

nte

Actividades en grupo

Actividades en supragrupo

Grupo

Actividades en individuales

Descripción de

Tareas de lugar Descripción de Tareas de Transición

Llevadas a cabo en

Individuo

Actúa en

Actúa en

Llevadas a cabo en

Individual



Página | 43

3.1.2. Propuesta de metodología de desarrollo de software para objetos virtuales de

aprendizaje -MESOVA

El modelo que propone (Castrillón, 2011) para el desarrollo de objetos virtuales de

aprendizaje, se basa en tres aspectos importantes a tener en cuenta y los cuales son:

especificación, el antes del análisis y diseño, la caracterización de la temática, el nivel

educativo y la especificidad pedagógica. Es importante resaltar la planeación del proyecto,

el análisis de requerimientos La metodología propuesta recoge elementos de las

metodologías XP, RUP, y UP, además de conceptos del modelo en espiral, incrementa y

evolutivo. La metodología se basa en diferentes principios, los cuales parten desde la

temática, pedagogía, plataformas tecnológicas, didáctica, documentación y diseño del

producto incluyendo actividades pertenecientes a la parte de desarrollo y pruebas.

La propuesta a través de una estructura secuencial con fases y actividades planteadas,

(figura 15) basada en 6 fases las cuales son la base fundamental de diseño y desarrollo de

cada uno de los módulos de integración y despliegue del objeto; además de las pruebas de

aprendizaje, consolidación, y entre cada una de estas existe un punto de control.

Figura 15. Fases de la metodología MESOVA. Adaptado de: (Castrillón, 2011)

Concepción del objeto

Diseño y desarrollo de

cada modulo

Integración y despliegue

del objeto

Pruebas de aprendizaje

Primer punto de control

Segundo punto de control

Tercer punto de control

Cuarto punto de control

Consolidación



Página | 44

Esta metodología se basa en conceptos de ciclo de vida de software con la variación hacia

objetos de aprendizaje, sin embargo, recomiendan hacer análisis de alcance, costos,

recursos necesarios entre otros.

3.1.3. Un modelo de proceso de desarrollo de software guiado por traceability

En este modelo (Vanzetti, 2006) presentan el proceso de desarrollo de software a partir de

un modelo RT, agrupando en cinco categorías como calidad, satisfacción del cliente,

recuperación de información y mantenimiento.

Se relacionan el software con el conocimiento, un concepto importante que se tiene en

cuenta es el proceso de desarrollo de software, ya que involucra una serie de pasos y

actividades asociadas a la producción de software; presenta 4 actividades comunes las

cuales son: especificación del software, desarrollo, validación y evolución del software.

Adicionalmente hace un estudio de las características del proceso de desarrollo de

software, señalando que un buen proceso debe conocer el costo, el cronograma y su

resultado debe tener buena funcionalidad.

Según (Vanzetti, 2006) el proceso orientado a proyectos pequeños se agrupan de acurdo

con factores como el tamaño de la organización, complejidad del proyecto e interacciones.

Para la gestión de requerimientos se muestra como la capacidad de software a ser

desarrollado según STD.310.12 de IEEE o también la condición o capacidad de resolver un

problema, proceso de servicio que debe proveer y las restricciones bajo las cuales deben

operar al establecer los requerimientos se aclaran y especifican las necesidades del cliente

y los usuarios, puede haber inconvenientes relacionados con los requerimientos debido a

no reflejar la necesidad de los usuarios, ser incompletos y malentendidos o desacuerdos

entre los clientes.

Para este modelo, los Requerimientos de traceability es la habilidad para describir y seguir

la vida de un requerimiento tanto hacia adelante como hacia atrás, en donde un sub modelo

de este es la gestión de requerimientos con sus estándares y especificaciones que se deben

tener en cuenta para esto, en donde se especifican las diferentes necesidades para el

desarrollo de un proyecto, sin embargo, se hace relaciones entre los diferentes escenarios



Página | 45

y objetos del sistema. Otros sub modelos como el de fundamentación, desing/allocation,

compliance verification se tienen en cuenta para el diseño y desarrollo de la aplicación.

Figura 16. Proceso de desarrollo de Software. Adaptado de: (Vanzetti, 2006)

3.1.4. Modelo para el desarrollo de software basado en competencias. MODESEC

Este modelo (Toscano & Caro, 2015) se basan en competencias, teniendo en cuenta la

legislación colombiana y de acuerdo a estudios donde manifiestan que los modelos son

más dedicados a la parte de software y multimedia.

Se muestra una sustentación frente a modelos existentes en donde expresan que estos

modelos no presentan información con competencias, y que las competencias forman parte

del eje integrador del aprendizaje, además muestran una sección de elementos, los cuales

determinan la interfaz de usuario, un listado de conceptos se obtienen las competencias, y

1.0 Modelizar la organización

2.0 Especificar los requerimientos

de software

3.0 Validad la

especificación de requerimientos de

software

4.0 Desarrollar la arquitectura

del sistema

5.0 Fundamentar

Organización

Organización

Actividades codificación



Página | 46

da origen al diseño de contenidos, el contexto determina las características del ambiente y

los indicadores sirven para la evaluación del software.

En general el modelo integra 5 fases como diseño educativo, diseño multimedial, diseño

computacional, producción y aplicación. En el diseño educativo se centra en la parte

pedagógica, de contenidos, didáctica e instruccional para el área o tema que se va a

desarrollar la aplicación. En el multimedial se basa en el diseño especificarte del ambiente

como de la navegación y de más elementos que contendrá a nivel de recursos didácticos.

El diseño computación tiene análisis de requerimientos para la parte de software, se basa

en algunos diagramas UML como casos de uso, clases, objetos y secuencias para el diseño

del sistema computacional. La etapa de producción se codifica en un lenguaje de

programación la cual incluye varias etapas comunes; finalmente la fase de aplicación, se

presenta el producto terminado.

Figura 17. Modelo para el desarrollo de software educativo basado en competencias. Adaptado de:

(Toscano & Caro, 2015)

3.1.5. Metodología para el desarrollo de software multimedia educativo MEDESME

Esta es una propuesta de (García S, Vite C, Navarrate S, García S, & Torres C, 2016) la

cual está diseñada para trabajar por etapas y fases, en la cual cada una de esta genera un

subproducto que tiene un seguimiento lógico hacia las etapas y fases posteriores.

FASE I DISEÑO EDUCATIVO

FASE II DISEÑO MULTIMEDIAL

FASE III DISEÑO

CUMPUTACIONAL

FASE IV PRODUCCIÓN

FASE V APLICACIÓN



Página | 47

La metodología propuesta tiene 8 fases que inician en concepto o preproducción, análisis,

diseño, desarrollo, implementación, evaluación y validación, producción y elaboración del

material.

Esta metodología su fundamento es pedagógico por lo tanto el análisis, diseño, desarrollo

y demás se basa en la parte de requerimientos técnicos y tecnológicos para adquirir un

aprendizaje, en la cual se debe tener en cuenta la ayuda de profesionales en pedagogía,

didáctica y el área para el cual se desarrollará el producto final.

3.1.6. Metodología desarrollo de software para pymes de retail

Según (Colella, 2009) esta metodología se basa en las buenas practicas industriales, es

una adaptación de la metodología UP, se divide en etapas que inician en la recopilación y

análisis de la información, evaluación de procesos de información y propuesta

metodológica.

Metodología que utiliza enfoque iterativo e incremental, permitiendo la generación de un

producto en cada implementación, para la cual consideran que cada entrega es una

iteración.

En cada una de las fases de la metodología se desarrolla cada uno de las siguientes

actividades. Fase de inicio, se define factibilidad del proyecto, aprobación por parte del

cliente, se hace el levantamiento de requisitos, análisis de riesgos, diseño previo; en la fase

de elaboración, se detallan los requerimientos, casos de uso, se determinan los alcances

reales del proyecto, se refina su arquitectura, eliminar riesgos, se debe contar con

herramientas y ambientes de prueba, la fase de construcción, se determina la evolución del

software, con sus correspondientes entregas en cada iteración, se programa entrega final

y se construye la documentación requerida. La fase de transición es el seguimiento al

producto implementado, entrega del producto, se hace documentación y capacitación y

finalmente la fase de evolución se hace mantenimiento correctivo al producto.

En esta propuesta las actividades son desarrolladas en su mayoría por analistas,

arquitectos, desarrolladores y el cliente que interviene en menor medida.



Página | 48

Figura 18. Procedimiento general de la metodología. Tomado de: (Colella, 2009)



Página | 49

3.1.7. Hacia un modelo de madurez para apoyar el desarrollo de software dirigido por

modelos.

Según (Holzer & Ondrus, 2009) es un modelo ágil y especifico de desarrollo dirigido por

modelos y aplicable en pequeñas organizaciones de desarrollo de software, en donde

evidencia que el fin de los modelos es pasar de un modelo descriptivo a un modelo

prescriptivo, haciendo que el modelo sea el sistema de información.

Es una propuesta basan en los procesos de la norma ISO/IEC 12207 la cual toma de esta

un conjunto de procesos, los cuales son agrupados en categorías.

Figura 19. Modelo propuesto. Tomado de: (Holzer & Ondrus, 2009)



Página | 50

3.1.8 Otras metodologías de desarrollo de software

3.1.8.1. Metodología de diseño, desarrollo y evaluación de software educativo.

(Cataldi, 2000) Se centra en los requerimientos pedagógicos, necesidades educativas, y

tecnológicas utilizando diferentes técnicas especializadas para cada una de las etapas; es

necesario de personal capacitado y con conocimiento en cada una de las herramientas y

técnicas propuestas para el diseño y construcción del material.

3.1.8.2. Metodología de desarrollo de software basada en modelos. (Nader,

2014) Enfocada hacia los procesos de negocio, se desarrolla en ocho fases que inician con

la fase de modelado de proceso de negocio, gestión de requisitos, análisis de requisitos,

desarrollo, pruebas, despliegue operación, mantenimiento y gestión del proyecto. Como

aspecto importante es que esta metodología se conoce los procesos de negocio de la

compañía y las mejoras que puede tener, con análisis y determinar su solución para luego

crear los modelos de los procesos. En la fase de requisitos se deben identificar y modelar,

a través de la agrupación de estos mediante grupos de trabajo los cuales definen las tareas

a realizar para cumplir con estos. En la mayoría de estas etapas intervienen expertos en

análisis, diseño y desarrollo de sistemas de información.

3.1.8.3. Metodología de desarrollo de software en entidades de educación

superior MEDESOFT. (García P, 2009) Esta metodología es una adaptación de varios

modelos, y normas internacionales para el desarrollo de software, parte de la

contextualización de software, presentando y mostrando cada uno de los modelos y normas

con sus características importantes, su desempeño, fortalezas y debilidades para así

abstraer aspectos importantes y útiles para el diseño de la nueva metodología.

La implementación de la metodología parte de la descripción de la organización, muestra

su plan estratégico, para luego haces un diagnóstico de la situación actual, teniendo en

cuenta factores como económicos, geográficos, políticos y tecnológicos entre otros; se hace

un análisis de las fortalezas y debilidades que se tienen, para finalmente presentar una

matriz FODA.

Es una metodología académica, la cual no se evidencia claramente cada uno de los pasos

y procesos que normalmente tiene este tipo de metodologías, está orientada hacia la parte

educativa, ya que muestra un análisis de aspectos curriculares de una institución educativa.



Página | 51

3.2. METODOLOGÍAS TRADICIONALES.

Para el desarrollo de la investigación, se tienen en cuenta algunas de las metodologías

tradicionales, las cuales se encuentran en los documentos de texto y que por tanto son muy

conocidas tanto académicamente como profesionalmente, y teniendo en cuenta que según

estudio realizado por (Vesela & Krbecek, 2016) sobre el uso de metodologías para el

desarrollo de software, muestra que el 58% de la población encuestada usa metodologías

de desarrollo agiles, el resto de la población utiliza metodologías tradicionales;

adicionalmente, se muestra que la metodología scrum es la más conocida, las demás son

conocidas en menor proporción, se tendrán en cuenta para el estudio.

Según estudio realizado por (Vesela & Krbecek, 2016) sobre el uso de metodologías para

el desarrollo de software, muestra que el 58% de la población encuestada usa metodologías

de desarrollo agiles, el resto de la población utiliza metodologías tradicionales;

adicionalmente, se muestra que la metodología scrum es la más conocida, las demás son

conocidas en menor proporción.

3.2.1 Metodología XP

Según (Yolanda, 2013) es una de las metodologías agiles para el desarrollo de software,

es una solución en proyectos cortos, ya que conlleva menos protocolos, y se basa en una

serie de reglas que están centradas en la necesidad de del cliente, para esta es clave la

comunicación con el cliente para el cual se le deben cumplir a satisfacción sus necesidades,

promoviendo el trabajo en equipo. Se resalta en esta metodología la simplicidad, la

retroalimentación con el cliente y los desarrolladores.

Los personajes intervinientes para el desarrollo de esta metodología son el programador,

el cliente, consultor y si se requiere se pude utilizar un actor diferente de estos para realizar

las pruebas y seguimiento del desarrollo de software.

Esta metodología tiene en cuenta el costo, tiempo, calidad y alcance para el desarrollo de

cualquier proyecto. Se basa en iteraciones de desarrollo las cuales son cortas y se hace un

entregable al finalizar cada una de estas y se realiza análisis, diseño, desarrollo y pruebas.



Página | 52

Las fases que contempla básicamente XP son la fase de Exploración, se basa en la historia

de los usuarios con respecto al producto a desarrollar, y los programadores verificaran las

herramientas a utilizar en el proyecto. En la fase de planificación de la entrega el cliente

establece prioridades de entrega de acuerdo a las historias de usuario, se analiza la

información correspondiente a la primera entrega. Fase de iteraciones, se hacen varias

iteraciones de tiempos cortos (semanas). Fase de producción en esta se hacen pruebas al

sistema y se revisa el rendimiento, se pueden incluir nuevas características al sistema. En

la fase de mantenimiento, se le hace soporte al cliente.

3.3. ANALISIS DE LA INFORMACION

Para el estudio se toman como referencia diez modelos de desarrollo de software, creados

en Colombia y países latinoamericanos para orientar alguna solución específica,

adicionalmente se tuvieron en cuenta tres de las metodologías de desarrollo de software

que más se usan en el contexto educativo, y por lo tanto son referentes a nivel empresarial.

Durante el análisis de la información, se toma como referencia las etapas de los modelos

tradicionales, así como el requerimiento de profesionales y expertos que son necesarios

para el desarrollo de estos modelos, otro elemento importante que se relacionó en el estudio

es el conocimiento que implica tener para poder seguir y desarrollar una aplicación.

Finalmente se realiza una comparación de elementos a través del costo, tiempo,

conocimientos y personal que se requiere para el uso e implementación de un modelo.

Al revisar la información, y extraer las variables involucradas en el estudio, y facilitando el

proceso de análisis y caracterización, se creó la tabla 1 la cual especifica una calificación o

peso que se le puede asignar a la información que se esté valorando; en la descripción de

nivel se encuentra: muy alto, alto, medio, bajo y muy bajo, a cada una de estas se les asigna

el valor del nivel el cual está comprendido entre 1 y 5, en donde 1 es muy bajo y 5 es muy

alto. Únicamente se asigna el valor del nivel y la interpretación se hace de acuerdo a la

variable en estudio.



Página | 53

Tabla 1. Escala de niveles de valoración

Descripción de nivel Nivel

Muy alto 5

Alto 4

Medio 3

Bajo 2

Muy bajo 1

Fuente: Autor

3.3.1 Análisis teniendo en cuenta las etapas involucradas

Al realizar el estudio, se encontró que hay por lo menos tres etapas en común entre las

diferentes metodologías y modelos; la primera es de análisis, que tiene que ver con la

necesidad requerida por el cliente, generalmente se debe utilizar diferentes estrategias para

poder extraer la información y representarla a través de diagramas; la segunda etapa que

es la de diseño, en donde se modela lo que le transfieren la anterior fase, se utilizan técnicas

y modelos de representación de un sistema de información, puede ser a través de software

diseñado específicamente para esto. La etapa de desarrollo la cual transforma el diseño a

través de un lenguaje de programación en un producto terminado, teniendo en cuenta los

modelos y diagramas de las anteriores etapas. Hay metodologías que tienen otras etapas

que hacen parte de estas, para el estudio no se tuvieron en cuenta ya que no se encontró

especial relevancia.

En la tabla 2 se encuentran los modelos en estudio y las etapas que tienen asociadas en

común. Se les asigna un peso de acuerdo al grado de inclusión en cada una de los modelos

en estudio, en la columna “Promedio” se suman los tres datos anteriores y se promedian,

esto con el fin de ver cuál es el peso que tiene el modelo en estudio con respecto a las tres

fases analizadas. Se indica que el valor asignado en cada una de las variables analizadas

y por cada una de los modelos, se asigna de acuerdo al estudio y visión del autor con

respecto a cada una de estas, adicionalmente se asociaron algunas de estas a las etapas

tradicionales, ya que no todos los modelos los nombran así.



Página | 54

Tabla 2. Análisis por etapas

No. Modelos y metodologías Análisis Diseño Desarrollo Promedio

1 Un Modelo para el Desarrollo Cooperativo de Software 5 5 5 5,0

2 Propuesta de metodología de desarrollo de software para objetos virtuales de aprendizaje -MESOVA

4 4 4 4,0

3 Un modelo de proceso de desarrollo de software guiado por traceability

4 4 3 3,7

4 Modelo para el desarrollo de software basado en competencias. MODESEC

3 4 4 3,7

5 Metodología para el desarrollo de software multimedia educativo MEDESME

3 3 3 3,0

6 Metodología desarrollo de software para pymes de retail 3 3 3 3,0

7 Hacia un modelo de madurez para apoyar el desarrollo de software dirigido por modelos.

4 4 4 4,0

8 Metodología de diseño, desarrollo y evaluación de software educativo

4 4 4 4,0

9 Metodología de desarrollo de software basada en modelos

4 4 4 4,0

10 Metodología de desarrollo de software en entidades de educación superior MEDESOFT

4 3 4 3,7

11 XP 3 3 3 3,0

12 SCRUM 3 3 3 3,0

13 UP 5 5 4 4,7

Fuente: autor

Para el análisis se promedia las etapas en cada uno de los modelos, esto con el fin de ver

en qué medida influyen estas en cada modelo.

En la gráfica 2 se puede observar el promedio de cada uno de los modelos analizados, en

donde se evidencia que la mayoría tienen un uso entre medio y alto grado de las etapas

propuestas en el estudio, demostrando que estas etapas son necesarias en el desarrollo

de una aplicación de software. Una etapa que o se valoró pero que siempre se tiene en

cuenta es la de pruebas; debido a que el estudio se basa primordialmente en estas tres

primeras etapas, esta última es de gran importancia ya que se utiliza para valorar y verificar

que la aplicación desarrollada cumple con los objetivos inicialmente planteados.



Página | 55

Grafica 2. Grado de uso de las etapas en cada uno de los modelos en estudio

Fuente: autor

3.3.2 Análisis de acuerdo al conocimiento requerido

Este análisis está basado en que las personas que sigan cualquiera de los modelos, deben

tener cierto grado de conocimiento, experiencia y experticia, específicamente en cada una

de las etapas mencionadas. El estudio se basa en que las metodologías y modelos hablan

del experto que debe desarrollar la metodología; aunque no siempre se utiliza una para

cada etapa, se puede notar que cada una de estas lo requiere y este generalmente es

diferente al cliente.

Se ponderó como se puede ver en la tabla 3, en la cual es notoria tener conocimiento en

medio o alto nivel en el área de TIC, para poder hacer seguimiento a un modelo. Aunque

en algunas metodologías es bajo, existen otros parámetros como el grado de

retroalimentación que requiere el cual es de forma cíclica, lo cual indica que si se suma

tendría un gran valor comparado con las demás.

5,0

4,0

3,7

3,7

3,0 3,0

4,0 4,0 4,03,7

3,0 3,0

4,7

0,0

1,0

2,0

3,0

4,0

5,0

6,0

1 2 3 4 5 6 7 8 9 10 11 12 13

Valo

ració

n p

rom

edio

del m

odelo

Modelos y metodogías en estudio

Promedio de las fases utilizadas

Modelos



Página | 56

Tabla 3. Ponderación por grado de conocimiento requerido

No. Modelos y metodologías Conocimiento

Requerido

1 Un Modelo para el Desarrollo Cooperativo de Software 5

2 Propuesta de metodología de desarrollo de software para objetos virtuales de aprendizaje –MESOVA

5

3 Un modelo de proceso de desarrollo de software guiado por traceability 5


5


4

6 Metodología desarrollo de software para pymes de retail 4


4

8 Metodología de diseño, desarrollo y evaluación de software educativo 4

9 Metodología de desarrollo de software basada en modelos 4


4

11 XP 3

12 SCRUM 3

13 UP 5

Fuente: autor

3.3.3 Análisis teniendo en cuenta la especialidad requerida en cada etapa

Otro elemento a analizar es la especialidad que debe tener la persona o personas que

pretenden desarrollar cada una de las etapas planteadas, en la tabla 4 se puede observan

los más requeridos. Se le asigna un valor el cual representa el nivel de participación durante

el desarrollo de la etapa en las metodologías o modelos de estudio.

El analista generalmente se considera una persona experta y con amplio conocimiento en

análisis de información y formación en ingeniería de sistemas, de requerimientos, o afines,

para el caso del arquitecto de software, es quien hace los respectivos modelos lógicos e

interfaces, debe tener conocimiento y experiencia en el manejo y uso de herramientas que

faciliten este proceso, en algunos casos este trabajo lo desarrolla el analista con el apoyo

de un experto en diseño. El desarrollador que puede ser un grupo de personas expertas en



Página | 57

programación, traducen el diseño lógico e interfaces en un lenguaje de código, que luego

de un proceso se convierte en el producto final.

Tabla 4. Análisis por especialidad

No. Modelos y metodologías Analista Arquitecto Desarrollador Otros

1 Un Modelo para el Desarrollo Cooperativo de Software

5 4 5 5

2 Propuesta de metodología de desarrollo de software para objetos virtuales de aprendizaje -MESOVA

3 1 4 5

3 Un modelo de proceso de desarrollo de software guiado por traceability

4 4 4 0


3 2 4 3


3 3 4 5

6 Metodología desarrollo de software para pymes de retail

5 4 4 0


4 4 4 2

8 Metodología de diseño, desarrollo y evaluación de software educativo

4 4 4 4

9 Metodología de desarrollo de software basada en modelos

4 4 5 2


3 2 4 5

11 XP 4 4 5 0

12 SCRUM 4 4 5 0

13 UP 5 5 4 4

Fuente: autor

Al graficar se puede observar que los modelos requieren en promedio un nivel de

conocimiento de medio a alto para poder hacer seguimiento a través de alguno de los

modelos de estudio, como se puede observar en la gráfica 3. En algunos casos existe el

requerimiento de otro tipo de personal experto en otros temas necesarios para el desarrollo

del modelo, el cual no se tuvo en cuenta, sin embargo, se es importante resaltar que es

adecuado y pertinente acudir a expertos según sea el requerimiento.



Página | 58

Grafica 3. Promedio del nivel de requerimiento de especialidad en las etapas de los modelos

Fuente: autor

4,75

2,75

4

33,25

4,254

3,75

3

2,75

4 4

4

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

5

1 2 3 4 5 6 7 8 9 10 11 12 13

Escala

de E

valu

ació

n

Modelos y metodologías en estudio

Promedios de especialidad requerida

Modelos



Página | 59

4. MODELO PARA EL DESARROLLO DE APLICACIONES

4.1. INTRODUCCION

Con el uso de las TIC muchas personas quieren crear aplicaciones, otras con

conocimientos hacen programas ya sea para manejar su agenda personal, compartir

información, para hacer cálculos matemáticos como diversión o como actividad profesional

en una empresa, sin embargo, la tarea de desarrollo de una aplicación no es fácil, es

necesario de profesionales con experiencia y conocimientos, los cuales crean aplicaciones

de propósito específico para una empresa o entidad en particular. (Sommerville, 2011b)

Aunque existen diferentes modelos para el desarrollo de software con etapas y necesidades

de personal especializado en común; a continuación, se presenta un modelo basado en las

etapas de los modelos tradicionales, pero con condiciones, requerimientos y personal como

el cliente involucrado de primer plano en el proceso de análisis y diseño de su aplicación.

La propuesta está diseñada por etapas y se fundamenta principalmente en las dos primeras

etapas, ideación y requerimientos basado en la posibilidad que tiene el mismo cliente en la

intervención en estas. Para las etapas posteriores se debe tener conocimiento o ser experto

en el área de software dado que son propias de esta.

4.2. MODELO PROPUESTO

El modelo está compuesto de cinco etapas básicas (figura 20), cada una de estas con

diferentes procesos, permitiendo que una persona puede hacer seguimiento de forma fácil

y pueda avanzar en el proceso de desarrollo su propia aplicación requerida. El modelo se

basa en especificaciones del ciclo de vida y otras metodologías las cuales le permite hacer

retroalimentación a nivel interior y entre cada una de las etapas propuestas, este describe

una representación simplificada de dicho proceso y permite predecir su comportamiento

(De Antonio); además como objetivos determinar el orden de las etapas y actividades.



Página | 60

IDEAR

REQUERIR

MODELAR

PROGRAMAR

EVALUAR1

2 3

5

76

Figura 20. Esquema general del modelo propuesto. Fuente: autor

La importancia del modelo radica en la concepción de la idea, que surge de una necesidad

requerida. Lo que se plantea es que el cliente a través de los elementos presentados pueda

realizar esta etapa, y además pueda abordar sin ningún problema la etapa de requerir, y

utilizando las actividades allí planteas pueda generar la matriz expuesta para esto. A partir

de la etapa 3 se recomienda la ayuda de un profesional en área si no posee dicho

conocimiento.

Las dos primeras etapas tienen un proceso de retroalimentación continua, la etapa 3 lo hace

con la 1, y es importante ya que permite verificar que lo que se ideo corresponda con lo que

se está diseñando. En las dos últimas se propone este proceso para que el producto tenga

el mejor acabado y las pruebas que son un factor importante en el proceso de desarrollo de

software permitan verificar y validar el producto final.

De acuerdo al esquema general del modelo propuesto, se establecieron dentro de cada

etapas, actividades y pasos que conducen al seguimiento y desarrollo de forma adecuada,

generando seguridad y confianza para un desarrollo asertivo. En la figura 21 se muestran

en detalle las cinco etapas que componen este modelo, además de la interacción que hay

entre cada una de ella, la cual se describe a continuación, desde cada uno de las

actividades que se tienen que desarrollar.



Página | 61

IDE

AR

FA

CT

OR

Eco

nóm

ico

Soci

al

Pers

onal

Em

pre

sa

NE

CE

SID

AD

Activid

ad

Activid

ad

Activid

ad T

area

Tar

ea

Tar

ea

Obje

tivo

Ob

jetivo

PL

AN

EA

R

Ve

rifica

r

ET

AP

A 1

ET

AP

A 2

ET

AP

A 3

ET

AP

A 4

ET

AP

A 5

RE

QU

ER

IR

Tip

os

Fís

icos

Hum

anos

Téc

nic

os

Ma

triz

de

Re

que

rim

iento

s

Cla

sific

ar

Fun

cio

nale

sN

o fun

cio

nale

s

Pro

ye

cta

r

PR

OG

RA

MA

R

Inte

rpre

tar

Norm

as

Mo

delo

s

Cod

ific

ar

MO

DE

LA

RC

lasifi

car

Rela

cio

nar

Dis

eña

rV

erifica

r

EV

AL

UA

R

Té

cnic

as

de

Pru

eba

s

Usua

rios

inte

ren

os

Usua

rios

exte

rno

s

Mo

delo

s d

e

de

sarr

ollo

Figura 21. Modelo general ampliado. Fuente: autor



Página | 62

4.2.1. Etapa 1, Idear

En el estándar ISO/IEC 12207 (Singh, 1996b) el ciclo de vida inicia con una idea que puede

ser satisfecha a través de un software teniendo en cuenta los requerimientos del mismo, en

este documento se expresa que el ciclo de vida es agrupado principalmente en tres clases

la cuales son primarias, de soporte y organizacional, cada una de estas con actividades

propias de cada una; (Jiménez & Abarca, n.d.) adicionalmente está compuesto por un

conjunto de tareas que son un conjunto de acciones, que esta además tiene entradas de

datos información o centro y produce salidas que también pueden ser datos información o

control.

Esta etapa es considerada como la más importante de la metodología ya que aquí se

fundamenta la idea de lo que se pensó realizar, por lo tanto, es recomendable elaborar un

mapa conceptual de las ideas que le surjan para el desarrollo del proyecto, refleja una idea

de puntos comunes y diferencias, esto permite generar nuevas ideas, durante esta actividad

tenga en cuenta que el origen de la idea, pudo surgir debido a algún tipo de necesidad. En

la figura 22 se encuentra el diseño de la primera etapa, en donde se plantea a nivel general

el proceso que se debe seguir para poder cumplir con el desarrollo de la etapa.

IDEARFACTOR

Económico

Social

Personal

Empresa

NECESIDAD

Actividad

Actividad

Actividad

Tarea

Tarea

Tarea

Objetivo

Objetivo

PLANEAR

ETAPA 1

Figura 22. Etapa de concepción de la idea. Fuente: autor



Página | 63

Como la idea pudo surgir de una propuesta individual, también pudo ser a partir de un grupo

de trabajo, por lo tanto, se debe socializar, esto ayuda a construir cada una de las

actividades que la formaran, figura 23. Algunos de los aspecto que pudieron dar origen a la

idea tienen que ver con la necesidad de una página web, un sistema de información, o una

aplicación para dispositivos móvil, ya que según un estudio se observa el uso de estas

plataformas en donde: la tecnología utilizada, la cual puede ser Android o Apple,

actualmente la que más se usa es Android, según un informe de Gartner, el 81.7% de los

dispositivos móviles tienen instalado sistema operativo Android mientras que un 17.9%

tienen iOS de Apple.

Figura 23. Concepción de la idea. Fuente: autor

El proceso de gestación de la idea debe ser claro, además de facilitar teórica y

sistemáticamente cada uno de los requerimientos establecidos en el modelo. Para poder

desarrollar esta etapa se explica en detalle cada uno de los procesos del modelo, esto

permite entender y tener una mejor claridad, para hacer seguimiento en cada una de las

actividades propuestas en esa etapa.

4.2.1.1. Planear

Una vez se tenga la idea clara, es necesario planear su desarrollo conociendo elementos

claves relacionados con los posibles orígenes de la necesidad, algunos de estos pueden

ser: página web, una aplicación para dispositivos móviles, o una aplicación de propósito

específico; a continuación, se hace una contextualización general de algunos, con el fin de

adquirir conocimientos que le permita hacer el análisis y planeación de la necesidad.

¿Por qué página web? la página web es un sitio ubicado a través de internet, en donde se

publica información con texto, imágenes, videos y audios, esta generalmente solo permite

Concepción de

la idea

Individuo

Grupo de trabajo

Abierto al cambio

Interacción



Página | 64

la lectura presentadas; aunque hay páginas web dinámicas, esta solo permite interacciones

a través del texto o selección de opciones, las páginas web no deben ser confundidas con

un sitio web, ya que este último es una dirección en internet en la cual pueden existir varias

páginas web disponibles desde dicho sitio. Una página se programa generalmente en

lenguajes de programación de etiquetas y no necesita un conocimiento amplio en

programación; para diseñar una página web y colocarla en internet es un proceso que con

la ayuda de una persona con poca experiencia lo puede realizar.

¿Una base de datos? Cuando se habla de base de datos, se hace referencia a un sistema

de información, en este la información es organizada y ordenada a través de técnicas y

procedimiento de almacenamiento y consulta, de acuerdo a niveles de seguridad y roles de

usuario asignados a cada uno, además de un motor de base de datos o programa de

computación que controla estos datos, y un diseño de una base de datos con la información

organizada de tal forma que permita guardar, consultar o borrar.

¿Una APP? Debido al gran uso de dispositivos móviles, esta es una de las necesidades

más requeridas actualmente, por lo tanto debe saber que estos dispositivos tienen

diferentes herramientas tecnológicas que incluyen desde un GPS, giróscopo, brújula,

acelerómetro, bluetooth y NFC entre otras, cada una con funciones específicas, además de

conectividad de datos mediante un plan o wi-fi permitiendo el envío y recepción de

mensajes, archivos o imágenes entre uno o más usuarios que estén conectados

simultáneamente.

¿Internet? Es uno de los interrogantes que se deben conocer, pues es necesario cuando

se va a hospedar una aplicación a través de internet y en las aplicaciones móviles, ubicar

el programa para descargar e instalar. Teniendo en cuenta que actualmente no es

necesario arrendar una línea dedicada, un servicio DNS y comprar un servidor, además de

las licencias de software necesaria para instalar y administrarlo, para poder ofrecer los

servicios proyectados.



Página | 65

¿El Dinero? El recurso económico es otro de los elementos necesarios, es importante

disponer de buen recurso en el caso de adquirir equipos de cómputo, servicios de

hospedaje o licencias de algún software especializado que le ayude en alguna de las etapas

propuestas; además puede requerir una conexión a internet para garantizar el acceso a la

información continuamente.

¿Empleados? También hay que pensar en el recurso humano con el que dispone, en

alguna de las etapas es necesario contratar a un experto que le ayuda y facilite los procesos

en las diferentes etapas del proyecto, y para el desarrollo y puesta en marcha. Es

conveniente formar un equipo de trabaja en donde los integrantes pueden ayudar a

concretar la idea, a hacer una proyección y estudio del proyecto.

No es solo pensar en todo lo anterior; también hay requerimientos legales, posibles usuarios

que harán uso del proyecto, así como los clientes que pueden ser comerciales o de la

aplicación.

4.2.1.2. Necesidad

Una vez se ha contextualizado en la planeación, es importante conocer el origen de la

necesidad propuesta. En la figura 24 se encuentran algunas de las necesidades más

comunes actualmente. La económica que pude estar dada para captar recursos

económicos, la organizacional que surge de una empresa a entidad económicamente activa

la cual la requiere una solución para algún proceso interno, la social surge evidentemente

para dar solución a alguna necesidad vista en la comunidad de tal forma que facilite y ayude

a personas que tengan un problema de este tipo. La necesidad personal debe ser la más

clara ya que tiene la idea de lo que realmente necesita.



Página | 66

Figura 24. Tipos de necesidad. Fuente: autor

Luego de tener claro los pasos anteriores, el modelo expresa la necesidad como un

conjunto de actividades (figura 25) necesarias para cumplirse, cada una implícitamente

debe expresar un objetivo. Aquí es conveniente realizar un documento en donde se haga

una descripción clara de la necesidad, teniendo en cuentas la temática presentada en el

numeral anterior. También puede hacer un listado de las posibles actividades que surjan de

esta necesidad, esto también ayuda a definir los posibles requerimientos del proyecto.

Figura 25. La Necesidad. Fuente: autor

4.2.1.3. Actividad

En el ciclo de vida se define la actividad como un proceso que se tiene en cuenta para

desarrollar un software, esto hace referencia a las etapas de un modelo; aquí se expresa la

actividad como una o un conjunto de operaciones que se realizan para cumplir la necesidad

Necesidad

Económica

Social

Personal

Organizacional

Necesidad Actividad

Tarea n

Tarea 1

Objetivo Tarea 2

Objetivo

Objetivo

Objetivo



Página | 67

del software requerido. Figura 26. El proceso de almacenar, consultar, o borrar información

de una base de datos pueden ser una de las muchas actividades que puede listar, cada

una de estas tienen un objetivo propuesto el cual se evidencia claramente al enunciarlas;

para este proceso haga un listado de las posibles actividades, con su respectivo objetivo,

así como el responsable de ejecutar esta actividad dentro del sistema, que en este caso se

denomina interviniente, el cual puede ser un individuo u organización.

Figura 26. Determinación de actividad y acción. Fuente: autor

Las actividades deben ser claras y especificar el proceso o procesos que se desarrollan en

esta y cumplir con

Nombre: nombre de la actividad dentro de la etapa

Objetivo: objetivo a cumplir dentro de la actividad, este debe tener un fin primordial

dentro de la aplicación que está creando.

4.2.1.4. Tarea

Una tarea es un proceso que se hace o ejecuta dentro de una actividad, este al igual que

la anterior debe tener un objetivo propuesto, un ejemplo de tarea puede ser el hecho de

ingresar un dato dentro de una consulta de información, en donde además de realizar la

búsqueda, se debe validar el dato ingresado. La suma de varias tareas deben cumplir con

una actividad propuesta en el sistema.

Al determinar cada una de las tareas tenga en cuenta que esta pude ser dinámica o estática,

es decir que con el tiempo puede cambiar o permanecer con un valor constante. Figura 27.

Repita el proceso de los ítems nombrados anteriormente, listando las tareas con sus

objetivos, y los intervinientes que tiene, sin olvidar que deben estar asociadas a una

actividad propuesta.

Actividad Intervinientes

Individuo

Organización



Página | 68

Figura 27. Estados de una tarea. Fuente: autor

4.2.1.5. Dinámica de la etapa 1

Con la lista de actividades y sus respectivos objetivos, así como las tareas de cada

actividad, el proceso a seguir es el de asignarle un peso a cada uno de estos; este debe

ser un valor entre 1 y 100, siendo este último la mayor importancia dentro del proceso y el

otro indicaría que no es importante o que no es necesario en el desarrollo del software. Se

recomienda asignar el mayor peso a aquellas que hacen algún proceso relacionado con el

almacenamiento, consulta y actualización de información dentro de una aplicación o el

hecho de utilizar cualquiera de las herramientas tecnológicas de un dispositivo móvil, con

el fin de brindar alguna información correspondiente.

Del listado de actividades, y tareas se extraen los usuarios potenciales que tendrá su

aplicación, así como el rol de cada uno de estos, por lo tanto, asigne un nivel de importancia

para los usuarios o clientes del sistema, esto va a permitir asignar nos solo el rol sino el

nivel de seguridad y acceso que tendrá dentro del proyecto.

Revise cada uno de los formatos creados para registrar las tareas que tiene una actividad,

así como las actividades encontradas para poder cumplir con la necesidad planteada,

modifique la información de acurdo con lo encontrado en la revisión que está realizando;

hay que repetir este proceso las veces que sea necesario para evitar posibles

modificaciones a futuro.

Hay que repetir el procedimiento con cada una de las actividades y tareas, al finalizar este

proceso puede tener claramente una buena cantidad de información, la cual será muy útil

en el proceso de diseño del sistema, permitiendo definir la estructura lógica y de seguridad

Dinámica

Estática

Tarea



Página | 69

que tendrá su aplicación, además dará más claridad para poder clasificar los

requerimientos.

Del resultado de esta etapa debe tener un formato de especificación de la necesidad, y

actividades requeridas, así como las tareas que se deben cumplir dentro de la actividad, es

importante resaltar cual es el objetivo que cumple la tarea dentro de la actividad, y a su vez

la actividad dentro de la necesidad.

4.2.2. Etapa de requerir

El proceso de requerimientos es uno de los pasos muy valiosos dentro del desarrollo de

una aplicación de software, este realizará una búsqueda de estos requerimientos de una

forma más asertiva y segura que le permitirá y facilitará el desarrollo. (Project Management

Institute, 2013) Una vez se ha avanzado en con la etapa 1, es bueno revisar el alcance del

proyecto, y además recopilar los requisitos a través de la documentación y gestión de

necesidades que se obtuvieron en la etapa anterior, todo esto verificando los objetivos

planteados al inicio del proyecto.

Es recomendable que, si no es experto en el área, o en el equipo de trabajo no hay, debe

consultar a personas conocedoras o con experiencia en este tipo de labor, ya que el plan

de requisitos debe contener mínimo, como serán planificadas, monitoreadas y reportadas

las actividades asociadas a los requisitos; un proceso de priorización de requisitos, la

estructura de trazabilidad para reflejar qué atributos de los requisitos se escribirán en la

matriz de requisitos. (Project Management Institute, 2013)

En la figura 28 se muestra la etapa de requerir en general, con la estructura de proceso de

requerimientos necesarios para el desarrollo del proyecto, en concordancia con actividades,

tareas y estableciendo prioridades entre cada una de ellas, y así clasificar los

requerimientos teniendo en cuenta el tipo, y su funcionalidad; para finalmente generar una

matriz de requerimientos del proyecto.



Página | 70

ETAPA 2

REQUERIR

Tipos

Físicos Humanos Técnicos

Matriz de Requerimientos

Clasificar

Funcionales No funcionales

Figura 28. Etapa de requerimientos. Fuente: autor

4.2.2.1. Origen de los requerimientos

Según la real academia de la lengua española, define un requerimiento como: Acción y

efecto de requerir, (rae, n.d.) también puede ser una característica del sistema o una

descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito

del sistema; en términos generales se dice que los requerimientos tratan exclusivamente

sobre el quehacer de la aplicación, y no sobre los equipos que la soportan.(Cristián, 2011).

El proceso de recopilación de requisitos adecuado disminuye la posibilidad de pérdida de

tiempo, posible ahorro en los recursos económicos y posible fracaso del proyecto.

Un requerimiento puede tener dos proyecciones, (Palo, 2003; Ramesh & Jarke, 2001) hacia

adelante representa una proyección de mi aplicación, actividad o tarea que estoy

desarrollando o planeo ejecutar; también pueden existir requerimientos hacia atrás, lo cual

permite verificar si lo que se realizó antes está bien o falta de realizar algún ajuste al diseño

existente. En la figura 29 se puede observar el sentido que un requerimiento puede tener

en el modelo propuesto.



Página | 71

RequerimientosVerificar Proyectar

Figura 29. Sentidos de los requerimientos. Fuente: autor

Para la recopilación de requerimientos se utilizan diferentes técnicas y herramientas, esto

le ayudar a retroalimentar y concretar la información levantada en la etapa de idear. Algunas

de las más utilizadas son:

Entrevistas: obtiene información de los usuarios, clientes, patrocinadores y posibles

inversionistas que puede tener el proyecto; esto lo puede realizar a través de diálogo

directo con ellos, con preguntas elaboradas o espontaneas y registrando sus

respuestas.

Revisión documental. Consulta en informes de gestión de las organizaciones o

estamentos públicos relacionados con el tema proyecto, en donde se evidencie el

avance, la proyección la utilidad y demás elementos que sean importantes para su

proyecto. Estudios de mercado, modelos de negocio, políticas, procedimientos y

normas de leyes entre otras.

Revisión de otros proyectos. Le permite retroalimentarse y le ayuda a definir los

requisitos teniendo como elemento un producto definido, a su vez le permite

retroalimentarse en los objetivos que hasta el momento tiene definidos en el proyecto.

Para el seguimiento y análisis de la información, es necesario crear un documento en donde

debe estar registrado los datos que se extrajeron en el procedimiento anterior, ya que allí

pueden existir requerimientos importantes para el proyecto.

Un actor importante en el diseño y desarrollo del proyecto son los usuarios, ellos son los

que constantemente estarán haciendo uso de la aplicación, determinarán la seguridad y la

interfaz que tenga, la cual les facilitara el acceso y uso de la aplicación desarrollada. En

este momento hay que detenerse a pensar en los posibles usuarios y el rol que cada uno



Página | 72

tienen dentro de la aplicación, algunos preestablecidos pueden los que se presentan en la

tabla 5.

Tabla 5. Roles de usuario

Cuál es su rol dentro del proyecto

Líder

Usuario

Asesor

Técnico

Gerente

Dueño

Fuente: autor

Genera una tabla con los posibles usuarios que tendrá el proyecto, así como el rol que le

asignará, teniendo en cuenta las actividades creadas.

4.2.2.2. Tipos de Requerimientos

Para un mejor desarrollo de esta etapa, se clasifican los requerimientos en funcionales y no

funcionales; los funcionales son aquellas operaciones que se ejecutan sobre la aplicación,

los no funcionales son necesarios para desarrollo del proyecto o que la aplicación se pueda

ejecutar. En la tabla 6 se relacionan algunos de los requerimientos funcionales más

comunes de un software.

Tabla 6. Requisitos funcionales

Requisitos funcionales

Operaciones de entrada de datos

Operaciones de consulta de datos

Operaciones de almacenamiento de datos

Operación de reportes

Operaciones de acceso de usuarios

Operaciones de transferencia de datos

Fuente: autor

Dentro de los requerimientos no funcionales podemos encontrar los diferentes recursos que

son necesarios para el desarrollo del proyecto, el tecnológico el cual puede ser un

computador, dispositivo móvil o elementos que sean necesarios para el desarrollo y puesta



Página | 73

en marcha del software; en algunas ocasiones se necesita de licencias de software para el

modelamiento, diseño o desarrollo de las actividades del proyecto. En este caso es

recomendable la consulta con un experto en el área, el cual le puede asesorar y ayudar

tanto informativa como económicamente. (Figura 30) Teniendo en cuenta la figura, realiza

un listado de cada uno de los requerimientos planteados. Algunos de los requerimientos no

funcionales se muestran en la tabla 7.

Tabla 7. Requerimientos no funcionales

Producto Externo Otros

Requerimientos de funcionalidad

Requerimientos de seguridad

Estándares y normas

Requerimientos de Usabilidad

Requerimientos de comunicaciones

Requerimientos de implementación

Requerimientos de Fiabilidad

Requerimientos de seguridad

Requerimientos de instalación

Requerimientos de administración

Fuente: autor.

Figura 30. Tipos de recursos. Fuente: autor

4.2.2.3. Importancia de recopilar requisitos

El éxito del proyecto depende directamente de la participación activa de los interesados en

el descubrimiento y la descomposición de las necesidades en requisitos, y del cuidado que

se tenga al determinar, documentar y gestionar los requisitos del producto, servicio o

resultado del proyecto. (Project Management Institute, 2013) Los requisitos deben

recopilarse, analizarse y registrarse con un nivel de detalle suficiente que permita medirlos

una vez que se inicie el proyecto.

Recursos

Humanos

Físicos

Tecnológicos



Página | 74

4.2.2.4. Matriz de requisitos

Esta es una actividad importante en el proceso de requerir, ya que vincula los requisitos

generados con las actividades y tareas propuestas en la etapa de idear, además de ayudar

a asegurar que cada requisito agregue un valor al producto con los objetivos propuestos en

la necesidad del proyecto. Se debe relacionar entre otros aspectos: necesidades,

oportunidades, metas, objetivos y alcances del proyecto. Para el desarrollo de esta

actividad se propone la matriz de la tabla número 8, algunos de los atributos claves que se

pueden colocar en la matriz pueden ser: un identificador único, una descripción del

requisito, el fundamento de su incorporación, el responsable, la fuente, la prioridad, el

estado actual (puede ser vigente, cancelado, aplazado, aprobado) y la fecha, para esta

tabla se tiene en cuenta la afectación del requisito teniendo en cuenta que mucha de la

información a ser registrada en la tabla es tomada de los insumos de la etapa anterior, así

como de los proceso de requerir de estas. Además, para cerciorarse de que el requisito ha

satisfecho la necesidad, pueden incluirse otros atributos, tales como: estabilidad,

complejidad y criterios de aceptación.

Tabla 8. Matriz de requisitos

Nombre del proyecto: Número:

Fecha:

Objetivo de proceso de requisitos:

Requisito Afectación

ID Descripción Objetivos Tecnología Necesidad Usuarios OTRO

Nota: Una vez se coloque el id de requisito y la descripción, debe identificar en cuál de estas columnas tiene afectación, y colocar la combinación en valor comprendido entre el estado (de 1 a 3) y el nivel de afectación (es de 1 a 5) el cual indicara el peso y nivel de importancia del requisito

Estados Descripción de nivel Nivel

Vigente 3 Muy alto 5

Aplazado 2 Alto 4

Cancelado 1 Medio 3

Bajo 2

Muy bajo 1

Fuente: autor



Página | 75

Como procedimiento se debe diligenciar la matriz, como registro de todos los

requerimientos del proyecto, esta actividad tiene gran importancia para la etapa de diseño,

ya que de aquí se hace el modelo lógico que tendrá la aplicación.

4.2.3. Etapa de modelar

Se entiende el proceso de modelado en donde se presenta una visión o perspectiva de un

sistema, generalmente a través de una gráfica, y generalmente basado en alguna notación

que le permita unir las diferentes actividades propuestas. Uno de los modelos más utilizados

en el proceso de diagramación es el presentado por UML. (Booch, Jacobson, & Rumbaugh,

n.d.) Para el desarrollo de esta etapa es necesario contar con la ayuda de un profesional

con conocimientos en los diferentes modelos y normas del desarrollo de software, si no

tiene la suficiente formación. En la figura 31 se muestra el esquema general de esta etapa

ETAPA 3

MODELARClasificar

Relacionar

Diseñar

Figura 31. Etapa de modelar. Fuente: autor



Página | 76

Teniendo en cuenta que los procesos desarrollados en las dos etapas anteriores se crearon

las actividades presentadas en la etapa, permitiendo organizar de una forma adecuada la

información registrada en los formatos que se generaron en la etapa de idear y requerir.

4.2.3.1. Clasificar

Esta actividad se puede desarrollar aun si no conoce algún modelo de diagramación, y sin

la ayudad de alguna herramienta; por lo tanto, seleccione los formatos generados en la

etapa anterior, clasificándolos de acuerdo con los requerimientos funcionales del proyecto,

esto ayuda a estructurar el modelo lógico del sistema que se requiere. Presenta esta

información al experto y revisa nuevamente, hasta que se hayan verificado todos los

formatos.

4.2.3.2. Relacionar

En este proceso se tiene en cuenta la matriz de requerimientos, y de acuerdo a los

diferentes estándares para el modelo de una aplicación, relacionarla con los tipos de

usuario y actividades que se hayan propuesto; ya que este paso es desarrollado por un

diseñador o experto en el área, es conveniente realizar una continua retroalimentación con

el cliente, para así poder entender cada una das las actividades propuestas e interpretar lo

cual es el objetivo final de cada una.

4.2.3.3. Diseñar

El diseño es uno de los procesos importantes en la realización de un software, aquí es

donde se hace el diseño lógico que tendrá la aplicación, es conveniente que quede claro,

ya que el siguiente proceso lo realizará un programador y se guiará básicamente por el

diseño propuesto aquí.

Existen diferentes herramientas CAD para este proceso, además de modelos como el de

UML que es el que actualmente más se utiliza; por lo tanto, debe buscar un experto quien

desarrollara este proceso, el cual utilizando estándares presentara el diseño final, que se

ejecutara en la etapa de desarrollar.



Página | 77

4.2.4. Etapa de desarrollar

El documento (Holzer & Ondrus, 2009) presenta algunas de las tendencias del desarrollo

de aplicaciones móviles teniendo en cuenta las tecnologías existentes actualmente,

además hace un análisis de las implicaciones que pueden tener en cuanto la integración de

mecanismo, el uso de tecnología cerrada o abierta, portales centralizado o no, y finalmente

la implicación de elección de la plataforma, la cual se estudia desde aspectos como la

entrada hacia los consumidores, la carrera y las oportunidades que representan, y

finalmente la libertad de poder desarrollar una aplicación.

ETAPA 4PROGRAMAR

Interpretar

Normas Modelos

Codificar

Figura 32. Etapa de desarrollar. Fuente: autor

La programación de una aplicación de software, requiere de conocimientos en arquitecturas

de software, modelos de programación y herramientas de desarrollo, por lo tanto, el proceso

de selección de un experto debe ser adecuado, teniendo en cuenta que este realizará el

programa que finalmente se utilizará. Como la programación es una profesión que algunos

valoran y que por lo tanto el costo por un desarrollo puede ser elevado, debe contar con un

buen fondo económico, luego contacta alguno de esto para realizar tu propuesta.

Algunos criterios para seleccionar un buen desarrollador pude ser:

Económico



Página | 78

Afinidad y cercanía

Reputación del software que ha desarrollado

Especialización del software en el que desarrolla

Especialización de la consultoría que hace

Demostrar eficacia en empresas en donde ha desarrollado software

Conectividad para poder intercambiar información

Soporte y mantenimiento al software desarrollado

Adaptación a normas vigentes

Plataformas vigentes de desarrollo

Migración de datos

Seguridad

4.2.5. Etapa de pruebas

La etapa de pruebas es importante en un modelo de desarrollo de software, ya que esta

permite verificar que lo que realmente se desarrolló cumpla con los requisitos inicialmente

planteados, además se hace una retroalimentación de los procesos y actividades

propuestas y así eliminar los posibles errores encontrados. En la figura 33 se presenta el

proceso que se debe seguir para poder validad la aplicación.

EVALUAR

Técnicas de Pruebas

Usuarios

interenos

Usuarios

externos

Modelos de

desarrollo

Figura 33. Etapa de pruebas. Fuente: autor



Página | 79

Existen diferentes técnicas de pruebas de software, (IEEE, 1993, 1998) dependiendo del

objetivo que se quiera lograr, y el personal que la desarrolle. Sin embargo, tenga en cuenta

que por lo menos en el momento de planear las pruebas se le deben realizar las siguientes:

pruebas funcionales, relacionadas con el rendimiento del sistema, facilidad de uso,

disponibilidad de datos, operación de instalación y arranque, y seguridad. (Lamancha, n.d.;

Lara, 2013; Paz, 2016)

El personal elegido para realizar las pruebas debe tener habilidades y conocimiento en

desarrollo de software, y debe reunir algunos requisitos como: asumir el reto de encontrar

fallos, revisar los detalles a fondo, tener curiosidad en las opciones del software, capacidad

de actuar bajo presión, habilidades comunicativas y conocimiento funcional.



Página | 80

5. EVALUACION Y VALIDACION DEL MODELO

La evaluación del modelo es importante ya que permite comprobar las etapas y actividades

propuestas, además se da una retroalimentación la cual es una oportunidad para mejorar

los procesos de la propuesta.

5.1. POBLACIÓN OBJETIVO

EL modelo se planteó para ser la Facultad Tecnológica de la Universidad Distrital Francisco

José de Calas, por lo tanto, la población objetivo son los estudiantes y docentes de dicha

facultad. Para la validación del modelo se tomó una muestra de 15 personas, profesionales

en Ingeniería de sistemas o áreas comunes, los cuales en su mayoría han utilizado alguna

metodología para el desarrollo de software, y conocen diferentes modelos y metodologías

y que además están laborando en la Facultad Tecnológica.

5.2. APLICACIÓN DEL MODELO

Se reunieron a estos profesionales y se les hace la presentación del modelo, mostrando

cada una de las etapas, procesos y actividades que se deben desarrollan para poder

cumplir con la propuesta. Luego se les aplico una encuesta (formato anexo 1) para medir

diferentes variables que se relacionan a continuación.

Para unas preguntas se utilizó una escala con valores de 1 a 5 en donde 1 tiene una

representación de malo, y 5 tiene una representación de excelente; en otras se utilizó la

misma escala, pero el 1 indica bajo y el 5 representa alto grado.

5.3. ANALISIS DE RESULTADOS

Aplicada la encuesta a los participantes del proceso, se obtuvieron los siguientes resultados

en cada una de los cuestionamientos.

Pregunta 1: Las etapas propuestas en el modelo son:

Posibles respuestas: Adecuadas, Suficiente, Falta.

Análisis. El 60% de los encuestados respondió que son adecuadas, el 26.7% respondió

que son suficientes y solo el 13.3% que falta. (grafica 4) Esto indica que la propuesta tiene



Página | 81

las etapas necesarias para el desarrollo de una aplicación de software, y de acuerdo al

conocimiento de ellos cubren los proceso que una etapa de este estilo debe tener.

Grafica 4. Valoración de las etapas del modelo.

Fuente: Autor

Pregunta 2 columna 1: De acuerdo a la presentación del modelo, evalué la etapa en

cuanto a la Claridad

Posibles respuestas: 5. Excelente, 4. bueno, 3. Aceptable 2. regular, 1. malo.

Análisis. De acuerdo con los datos de la tabla 9, se puede evidenciar que la mayoría de

los encuestados respondió con una evaluación entre 4 y 5. Esto indica que la calidad de las

etapas presentadas es buena y acorde con los estándares de los modelos de desarrollo de

software. En la gráfica 5 es notable dicha descripción.

Tabla 9. Evaluación de calidad en cada etapa

Valor Etapas

Idear Requerir Modelar Programar Evaluar

1 0 0 0 0 0

2 1 0 1 0 0

3 1 4 1 0 1

4 10 6 9 11 8

5 3 5 4 4 6

Total 15 15 15 15 15

Fuente: Autor

60,026,7

13,3

Adecuadas

Suficientes



Página | 82

Gráfica 5. Evaluación de la calidad de cada etapa del modelo

Fuente: Autor

Pregunta 2 columna 2: De acuerdo a la presentación del modelo, evalué la Etapa en

cuanto a Grado de implementación.


Análisis. Se puede observar que la mayoría de respuestas fueron de un valor de 4, luego

aparecen las de un valor de 5 y en menor escala los demás valores; esto indica que el grado

de implementación de cada una de las etapas presentadas es de muy bueno, evidenciando

que se hizo un adecuado diseño de estas etapas.

Tabla 10. Evaluación del grado de implementación en cada etapa

Valor Etapas


1 0 0 0 0 0

2 0 0 1 0 0

3 1 4 1 0 2

4 10 4 6 12 6

5 4 7 7 3 7

Total 15 15 15 15 15

Fuente: Autor

Idear

Requerir

Modelar

Programar

Evaluar

0

2

4

6

8

10

12

1 2 3 4 5

Eta

pas

Núm

ero

de r

espuesta

s

Escala de valoración

Evaluación de la calidad de las etapas




Página | 83

Gráfica 6. Evaluación del grado de implementación en cada etapa

Fuente: Autor

Pregunta 2 columna 3: De acuerdo a la presentación del modelo, evalué la Etapa cuanto

a Conocimiento requerido.


Análisis. Se observa que en las dos primeras etapas la valoración más alta está en 3,

indicando que se entienden las etapas y que no se requiere de un alto grado de

conocimiento para poder hacer el seguimiento de estas, el cual concuerda con el modelo

propuesto, ya que se sugiere la ayuda de un experto en el área. Esta apreciación se puede

ver de forma clara en la gráfica 7.

Tabla 11. Valoración de cada etapa en cuenta a conocimiento requerido

Valor Etapas


1 1 1 0 0 0

2 2 0 1 0 0

3 5 5 3 2 3

4 3 5 4 6 6

5 4 4 7 7 6

Total 15 15 15 15 15

Fuente: Autor

Idear

Requerir

Modelar

Progra…

Evaluar

0

2

4

6

8

10

12

1 2 3 4 5

Eta

pas

Núm

ero

de r

espuesta

s


Grado de implementación de las etapas




Página | 84

Gráfica 7. Valoración de cada etapa en cuenta a conocimiento requerido

Fuente: Autor.

Pregunta 3. ¿De acuerdo a su experiencia cree que una persona sin conocimiento

técnico puede seguir el modelo?

Posibles respuestas: Si No

Análisis. En la gráfica 7 se observa que el 73.3% de los encuestados respondieron que, si

se puede hacer seguimiento al modelo en general, sin tener conocimiento técnico para

hacer, mostrando un alto grado de asertividad en la propuesta.

Gráfica 8. Respuesta del seguimiento al modelo

Fuente: Autor

Idear

Requ…

Modelar

Progr…

Evaluar

0

2

4

6

8

1 2 3 4 5

Eta

pas

Núm

ero

de r

espuesta

s


Valoración del conocimiento requerido


73,3

26,7

Si

No



Página | 85

Pregunta 4. ¿Cuál es su evaluación sobre el modelo de desarrollo de software presentado?

Posibles Respuestas: Excelente, Buena, Regular, Mala

Análisis. El 60% de los evaluadores muestran que el modelo es buen, el 26.7% indica que

es excelente como se evidencia en la gráfica 10, esto indica que las etapas y procesos

presentados en el modelo son coherentes y corresponden un modelo para el desarrollo de

software.

Gráfica 9. Evaluación general del modelo

Fuente: Autor

Pregunta 5. ¿En qué grado aporta al conocimiento el modelo presentado?

Posibles respuestas: alto, medio, bajo

Análisis. Según la gráfica 10 el 40% indica que tiene un aporte medio, también el 40% dice

que es alta, esto demuestra que el aporte que presenta la propuesta es medianamente alto.

Grafica 10. Aporte al conocimiento.

Fuente: Autor



Página | 86

Pregunta 6: ¿Qué cambiaría, adicionaría o eliminaría del modelo propuesto?

Posibles respuestas:

Análisis. A continuación, se presentan las respuestas presentadas por algunos de los

encuestados, los demás no respondieron nada. Esto se tomó como retroalimentación al

modelo, permitiendo fortalecer los procesos de algunas de las etapas propuestas.

Sumaria valor agregado y diferenciador de otras metodologías ya existentes

Adicionar manejo de comunicación con el usuario, periodicidad de pruebas y entregas

y estrategia de evaluación de calidad (proceso y producto).

Pruebas unitarias y de QA automatizadas

Lo dejaría tal cual, el modelo está diseñado para que se entienda lo más básico posible

Sensibilización en la evaluación, guía en la formulación de objetivos, automatización de

modelo de inteligencia en el levantamiento de requerimientos

Pregunta 7: ¿El modelo en su conjunto puede ser implementado en el contexto regional?

Posibles respuestas: Si No

Análisis. Esto expresa que el modelo en su conjunto tiene un alto grado de aprobación y

puede ser aplicado para el desarrollo de software.

Grafica 11. Implementación en el contexto regional

Fuente: Autor.

100,0

0,0 Grado de implementación en contexto regional

Si

No



Página | 87



Página | 88

CONCLUSIONES

Para el desarrollo de software existen diversas metodologías y modelos, los cuales hacen

que sea más difícil seleccionar la más adecuada; para realizar un análisis de estas, es

conveniente establecer un criterio de clasificación o de acuerdo al tipo de modelo que se

quiere orientar, ubicando una cantidad determinada por cada uno de los criterios definidos,

lo cual acotará y agilizará el estudio a realizar.

Para poder caracterizar las variables de las metodologías es necesario asociar algunas

etapas y procesos a aquellos que tienen las metodologías tradicionales, ya que existe

diversidad de estos, que de acuerdo con el diseño, enfoque y destinatarios del modelo o

metodología son creados y asociados.

Se generó una matriz de requerimientos que facilita el proceso de la etapa de

requerimientos, y además agiliza el proceso de diseño del software.

No es fácil proponer un modelo de desarrollo de software, debido a que los proceso

requeridos dependen de la necesidad del cliente, aunque la propuesta es clara, se

recomienda la ayuda de una persona experta en el área, si no se tiene el suficiente

conocimiento, esto permitirá un seguimiento más acertado en el uso del modelo.



Página | 89

MATRÍZ DE CONTRASTACIÓN DE OBJETIVOS

Objetivos Nivel de

cumplimiento Evidencias Observaciones

1

Analizar modelos y metodologías de desarrollo de aplicaciones orientadas al área TIC, existentes actualmente.

100%

En el capítulo 3 se encuentra el análisis de diferentes modelos y metodologías de desarrollo de software

Se tuvieron en cuenta algunos, ya que existen muchas metodologías y se basan en las mismas etapas tradicionales

2

Caracterizar las variables que pueden intervenir en el proceso de desarrollo de aplicaciones orientado al área de TIC.

100%

En el capítulo 3 se encuentran las tablas en donde se caracterizan algunas de las variables más comunes en las metodologías analizadas

Aunque existen otras variables diferentes a las analizadas, no son relevantes y por lo tanto no se tuvieron en cuenta durante el estudio.

3

Desarrollar el modelo propuesto, a través de la metodología utilizada para tal fin. 100%

En el capítulo 4 se presenta la propuesta del modelo.

El capítulo 4 presenta el desarrollo del modelo propuesto.

Proponer un modelo para el desarrollo aplicaciones en el área de TIC, dirigido a estudiantes de la Facultad Tecnológica de la Universidad Distrital Francisco José De Caldas.

100%

Se cumple teniendo en cuenta los objetivos anteriores y de acuerdo con la evaluación aplicada a expertos en el área.

De acuerdo a la valoración de los expertos el objetivo general se cumple en gran medida

Grado total de cumplimiento 100%



Página | 90

RECOMENDACIONES Y LÍNEAS FUTURAS DE INVESTIGACIÓN.

Hacer seguimiento al modelo con ayuda de una persona o a través de un grupo de trabajo,

esto permitirá que en las etapas de diseño y desarrollo haya mayor fluidez y pueda agilizar

el proceso de desarrollo del software.

Esta propuesta está basada en las dos primeras etapas del desarrollo del software; se

puede facilitar el proceso de diseño y desarrollo, con el uso de herramientas CAD que

ayudarían con estos procesos.

Continuar con la investigación para aplicarla en el contexto regional y nacional, ya que

pueden existir otras variables que alimenten el modelo y permitan mejorarlo.

Realizar la investigación con unidades y empresas que apoyen el emprendimiento y tengan

la necesidad con personas que necesitan desarrollar un producto en el área TIC, y no

poseen los recursos o el conocimiento para poder hacerlo.



Página | 91

REFERENCIAS

Acuerdo, C. A. U. D. (2015). Acuerdo 038 de 2015, modalidad de trabajos de grado.

Alpizar, L., García, F., & Arroyo, J. (2014). Modelo Básico de Desarrollo de Software, 193–

203.

Boehm, B. (2000). Spiral development : experience , principles , and refinements. Spiral

Development Workshop February 9, 2000, (July), 49. https://doi.org/CMU/SEI-2000-

SR-008

Booch, G., Jacobson, I., & Rumbaugh, J. (n.d.). Lenguaje Unificado. Retrieved from

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

Cámara de Comercio de Bogotá. (2015). Dinámica de la economía y el comercio exterior

en la región, 16.

Cantone, D. (2005). La biblia del programador, implementacion y debugging. International

Organization, Capítulo 2, 320.

Castrillón, E. P. (2011). Propuesta de metodología de desarrollo de software para objetos

virtuales de aprendizaje -MESOVA. Http://revistavirtual.ucn.edu.co/], ISSN 0124-5821

- Indexada Publindex-Colciencias (B), Latindex, EBSCO Information Services,

Redalyc, Dialnet, DOAJ, Actualidad Iberoamericana, Índice de Revistas de Educación

Superior E Investigación Educativa (IRESIE) D, (34), 113–137.

Cataldi, Z. (2000). Metodología de diseño, desarrollo y evaluación de software educativo,

75. https://doi.org/ISBN 960-34-0204-2

Chrissis, M. B., Konrad, M., & Shrum, S. (2009). CMMI guía para la integración de procesos

y la mejora de productos. CMMI® Guía para la integración de procesos y la mejora de

productos.

Colella, M. A. R. (2009). Metodología desarrollo de software para pymes de retail.

Competitividad, C. P. de. (2014). Informe nacional de competitividad 2013-2014.



Página | 92

Congreso, R. de C. (2006). Ley 1014 De 2006, Fomento a la cultura de emprendimiento.

Statewide Agricultural Land Use Baseline 2015, 1(enero 26), 12.

https://doi.org/10.1017/CBO9781107415324.004

Cristián, M. (2011). Introduccion a la Ingenierıa de Requerimientos, 1–58. Retrieved from

http://www.fceia.unr.edu.ar/~mcristia/publicaciones/ingreq-a.pdf

Díaz, J. M., Vicepresidente De Articulación, L., Privada, P., Ayala, R., Director, R., De, G.,

… Salgado, O. (2016). Comportamiento de la actividad productiva y del entorno

competitivo y empresarial. Observatorio Económico de La Región Bogotá-

Cundinamarca, 25. https://doi.org/ISSN: 2248-4515

García P, L. (2009). Metodología de desarrollo de software en entidades de educación

superior. MEDESOFT.

García S, E., Vite C, O., Navarrate S, M. Á., García S, M. Á., & Torres C, V. (2016).

Metodología para el desarrollo de software multimedia educativo. MEDESME. CPU-E,

Revista De Investigación Educativa, (23), 216–226. Retrieved from

http://www.redalyc.org/pdf/2831/283146484011.pdf

Holzer, A., & Ondrus, J. (2009). Trends in mobile application development. Mobile Wireless

Middleware, Operating Systems, and Applications-Workshops, 12, 55–64.

https://doi.org/10.1007/978-3-642-03569-2_6

Hugo, C., González, G., David, J., & Castellanos, G. (n.d.). Modelo de emprendimiento de

la industria de las Tecnologías de la Información (TI) para Colombia.

IEEE. (1993). IEEE Standard for Software Unit Testing (Vol. 1987).

IEEE. (1998). IEEE Standard for Software Test Documentation. IEEE Std 829-1998, 1998,

i. https://doi.org/10.1109IEEESTD.1998.88820

Jiménez, A. D. A., & Abarca, M. V. (n.d.). Un modelo para el desarrollo coperativo de

software.pdf.



Página | 93

Lamancha, R. E. Z. (n.d.). Proceso de testing funcional independiente.

Lara, M. (2013). Pruebas de software, 1–34. Retrieved from

https://netbeans.org/index_es.html

Mellon, C. (2010). CMMI para desarrollo, versión 1.3. CMMI Para Dsarrolo, Version 1.3, 23.

https://doi.org/CMU/SEI-2010-TR-033 ESC-TR-2010-033

Minncomercio, M. de C. I. y T. de C. (2009). Política de emprendimiento: versión final, 1–

53.

MinTIC. (2017). Boletin Trimestral de las TIC, Cifras Cuarto Trimestre de 2016.

MintTIC. (2016). Informe de gestión al CONGRESOCONGRESO DE LA REPÚBLICA 2016

Sector TIC, 100.

Mohd, N., Maat, S. M., & Mat, S. C. (2014). Factors influencing entrepreneurial intention

among engineering technology students. 8th International Conference on Ubiquitous

Information Management and Communication, ICUIMC 2014, 0–5.

https://doi.org/10.1145/2557977.2558013

Moraa, H., & Gathege, D. (2013). How ICT hubs models have impacted on the technology

entrepreneurship development. Proceedings of the Sixth International Conference on

Information and Communications Technologies and Development: Notes - Volume 2,

100–103. https://doi.org/10.1145/2517899.2517922

Nader, J. R. (2014a). Metodología de Desarrollo de Software : MBM ( Metodologia Basada

en Modelos ), (16), 111–125.

Nader, J. R. (2014b). Metodología de desarrollo de software MBM (Metodologia Basada en

Modelos), (16), 111–125.

Palo, M. (2003). Requirements Traceability Table of Contents. October, (October), 12.

Paz, J. M. (2016). Análisis del proceso de pruebas de calidad de software. Ingeniería

Solidaria, 12(20), 0–66. https://doi.org/10.16925/IN.V12I20.1482



Página | 94

Pérez, C. M. P. (2015). UNA METODOLOGÍA ÁGIL PARA EL DESARROLLO DE

SOFTWARE EN UNA COMPAÑÍA FINANCIERA.

Pressman, R. S. (2010). Ingeniería del Software un enfoque práctico. Chaos.

Project Management Institute. (2013). Guía de los fundamentos para la dirección de

proyectos. Global Standard (Vol. 87). https://doi.org/HD69.P75G845 2013 658.4’04--

dc23 2012046112

rae. (n.d.). DLE: requerimiento - Diccionario de la lengua española - Edición del

Tricentenario. Retrieved November 26, 2017, from http://dle.rae.es/?id=W6dALmQ

Ramesh, B., & Jarke, M. (2001). Toward reference models for requirements traceability.

IEEE Transactions on Software Engineering, 27(1), 58–93.

https://doi.org/10.1109/32.895989

Singh, R. (1996a). International standard ISO/IEC 12207 software life cycle processes.

Software Process: Improvement and Practice, 2(1), 35–50.

https://doi.org/10.1002/(SICI)1099-1670(199603)2:1<35::AID-SPIP29>3.0.CO;2-3

Singh, R. (1996b). International standard ISO/IEC 12207 software life cycle processes.

Software Process: Improvement and Practice, 2(1), 35–50.

https://doi.org/10.1002/(SICI)1099-1670(199603)2:1<35::AID-SPIP29>3.0.CO;2-3

Sociedades, S. de. (2015). Desempeño del sector Software 2012 -2014. Informe, 30.

Sommerville, I. (2011a). Ingeniería de software - Novena Edición.

Sommerville, I. (2011b). Ingeniería de software 9.

Toscano, R., & Caro, M. F. (2015). Modelo para el desarrollo de software educativo basado

en competencias. MODESEC, (January 2015).

Unitecnológica, U. T. de B. (2009). Hacia un modelo de emprendimiento de innovación

abierta socialmente responsable : caso Universdiad Tecnológica de Bolivar, 3, 33–44.



Página | 95

UPTC. (2007). Hacia un modelo de emprendimiento universitario. UPTC.

Valenzuela, J., Pavlich-Mariscal, & A, J. (n.d.). Hacia un Modelo de Madurez para apoyar el

Desarrollo de Software Dirigido por Modelos.

Vanzetti, J. J. (2006). Un modelo del proceso de desarrollo de software guiado por

traceability, 143.

Vesela, V., & Krbecek, M. (2016). Development methodologies of mobile applications.

International Conference on Interactive Mobile Communication, Technologies and

Learning (IMCL), (October), 16–17. https://doi.org/10.1109/MS.2003.1241363.

Yolanda, B. L. (2013). Metodología ágil de desarrollo de software XP, 10.



Página | 96

ANEXOS

ANEXO 1. MODELO DE LA ENCUESTA APLICADA

Universidad Distrital Francisco José de Caldas Maestría en ingeniería Industrial

Encuesta de valoración

Las etapas propuestas en el modelo son

Adecuadas Suficientes Faltan

De acuerdo a la presentación del modelo, evalué cada etapa según corresponda de

acuerdo a la valoración propuesta.

Claridad Grado de implementación

Aportes a cada etapa

Conocimiento requerido

Etapa 1

Etapa 2

Etapa 3

Etapa 4

Etapa 5

5. Excelente, 4. bueno, 3. Aceptable 2. regular, 1. malo.

¿De acuerdo a su experiencia cree que una persona sin conocimiento técnico puede seguir

el modelo?

Si No

Cual la evaluación sobre el modelo de desarrollo de software presentado

Excelente Buena Regular Mala

¿En qué grado aporta al conocimiento el modelo presentado?

Alto medio bajo

¿Qué cambiaría, adicionaría o eliminaría del modelo propuesto?

¿El modelo en su conjunto puede ser implementado en el contexto regional?

Si No

Documents

Propuesta de Modelo para el desarrollo de aplicaciones ...repository.udistrital.edu.co/bitstream/11349/7576/1/ReyesMozoJoséVicente2018.pdfPropuesta de Modelo para el desarrollo de