COLEGIO DE ESTUDIOS CIENTIFICOS Y TECNOLOGICOS DEL

ESTADO DE MEXICO

DESARROLLA APLICACIONES MOVILES PARA ANDROID

Mtro. Pablo Jaramillo López

“DESARROLLO DE UNA APLICACIÓN MOVIL QUE PERMITA

AGENDAR NUMEROS TELEFONICOS”

Fanny Michelle Ramirez Castillo

Brandom Alexis Pichardo
Sofia Vannesa
Diana Paola López Alvares
Gabriela Rebollar Bañuelos

Zacazonapan, Mex 17 Mayo 2023

 INTRODUCCION

Una aplicación móvil, también llamada app móvil, es un tipo de aplicación diseñada para
ejecutarse en un dispositivo móvil, que puede ser un teléfono inteligente o una tableta. Incluso si
las aplicaciones suelen ser pequeñas unidades de software con funciones limitadas, se las arreglan
para proporcionar a los usuarios servicios y experiencias de calidad.

A diferencia de las aplicaciones diseñadas para computadoras de escritorio, las aplicaciones

móviles se alejan de los sistemas de software integrados. En cambio, cada aplicación móvil
proporciona una funcionalidad aislada y limitada. Por ejemplo, puede ser un juego,
una calculadora o un navegador web móvil.

Debido a los recursos de hardware limitados de los primeros dispositivos móviles, las aplicaciones
móviles evitaban la multifuncionalidad. Sin embargo, incluso si los dispositivos que se utilizan hoy
en día son mucho más sofisticados, las aplicaciones móviles siguen siendo funcionales. Así es como
los propietarios de aplicaciones móviles permiten a los consumidores seleccionar exactamente las
funciones que deben tener sus dispositivos.
 CAPITULO I

Tema del proyecto

“DESARROLLO DE UNA APLICACIÓN MOVIL QUE PERMITA AGENDAR

NUMEROS TELEFONICOS”

Objetivo

Desarrollar una aplicación para dispositivos móviles plataforma Android que permita
agendar números telefónicos

Objetivos específicos

• Agendar número telefónico con nombre

• Llamar a los contactos agendados

Justificación del proyecto

La elaboración de una agenda permite el acceso a la información de los

contactos; evita la dependencia de un dispositivo único para su
almacenamiento e instalación.
Se busca ofrecer opciones similares a una central telefónica convencional,
como es el registro de números y llamadas telefónicas
 TECNOLOGIA MOVIL
La tecnología móvil es la tecnología que va adonde va el usuario. Consiste en dispositivos
portátiles de comunicaciones bidireccionales, dispositivos de computación y la tecnología de red
que los conecta.

Actualmente, la tecnología móvil se caracteriza por dispositivos habilitados para Internet

como smartphones, tablets y relojes. Estos son los últimos en una progresión que incluye
buscapersonas bidireccionales, computadoras portátiles, teléfonos celulares (teléfonos plegables),
dispositivos de navegación GPS y más.

Las redes de comunicaciones que conectan estos dispositivos se denominan en términos generales
tecnologías inalámbricas. Permiten que los dispositivos móviles compartan voz, datos y
aplicaciones (aplicaciones móviles).

La tecnología móvil es omnipresente y está creciendo. El número de usuarios de teléfonos

inteligentes ha superado los 3 mil millones y se espera que la fuerza laboral móvil mundial alcance
los 1.870 millones para 2022.

SISTEMAS OPERATIVOS MOVILES

Un sistema operativo móvil o (SO) móvil, es un sistema que controla un dispositivo móvil al igual
que los PCs que utilizan Windows o Linux, los dispositivos móviles tienen sus sistemas operativos
como Android, IOS entre otros. Los sistemas operativos móviles son mucho más simples y están
más orientados a la conectividad inalámbrica. A medida que los teléfonos móviles crecen en
popularidad, los sistemas operativos con los que funcionan adquieren mayor importancia. La
cuota de mercado de sistemas operativos móviles en el primer trimestre de 2016 era el siguiente:

Android 84,1 % (en países como España las diferencias son más significativas, donde Android tiene
el 90,8 % de la cuota de mercado.

• iOS 14,8 %
• Windows Phone 0,7 %
• BlackBerry OS 0,2 %
• Otros 0,2 %

Android tiene la mayor cuota, desde enero 2011, con más de la mitad del mercado, experimentó
un creciente aumento y en solo dos años (2009 a comienzos de 2011) pasó a ser el SO móvil más
utilizado.

Los 5 sistemas operativos para móviles más importantes dentro del mercado son:

1. Symbian OS: que fue producto de la alianza de varias empresas de telefonía móvil, entre
las que se encuentran Nokia como la más importante, Sony Ericsson, Samsung, Siemens,
 Benq, Fujitsu, Lenovo, LG, Motorola. Esta alianza le permitió en un momento dado ser
unos de los pioneros y más usados, pero actualmente está perdiendo vertiginosamente
cuota de usuarios aceleradamente; está por la versión 3. Está descontinuado y sin soporte.
2. Windows Phone, anteriormente llamado Windows Mobile es un S.O. móvil compacto
desarrollado por Microsoft, se basa en el núcleo del sistema operativo Windows CE y
cuenta con un conjunto de aplicaciones básicas, actualmente va por la versión 7. Está
diseñado para ser similar a las versiones de escritorio de Windows estéticamente y existe
una gran oferta de software de terceros disponible para Windows Mobile, la cual se puede
adquirir a través de la tienda en línea Windows Marketplace for Mobile.
3. Blackberry OS, desarrollado por la empresa canadiense RIM (Research In Motion) para sus
dispositivos. El sistema permite multitarea y tiene soporte para diferentes métodos
exclusivos de RIM.
4. IOS de los iPhones, anteriormente denominado iPhone OS creado por Apple originalmente
para el iPhone, siendo después usado en el iPod Touch e iPad. Es un derivado de Mac OS
X, se lanzó en el año 2007, aumento el interés con el iPod Touch e iPad que son
dispositivos con las capacidades multimedia del iPhone pero sin la capacidad de hacer
llamadas telefónicas, en si su principal revolución es una combinación casi perfecta entre
hardware y software, el manejo de la pantalla multitáctil.
5. Android es sin duda el líder del mercado móvil en S.O, está basado en Linux diseñado
originalmente para dispositivos móviles como los teléfonos inteligentes pero después tuvo
modificación para ser usado en tablets como es el caso del Galaxy Tab de Samsung ,
actualmente se encuentra en desarrollo para usarse en netbooks y PCs, el desarrollador de
este S.O. es Google, fue anunciado en el 2007 y liberado en el 2008; además de la creación
de la Open Handset Alliance, compuesto por 78 compañías de hardware, software y
telecomunicaciones dedicadas al desarrollo de estándares abiertos para celulares, esto le
ha ayudado mucho a Google a masificar el S.O, hasta el punto de ser usado por empresas
como HTC, LG, Samsung, Motorola entre otros.
 ANDROID
Android es un sistema operativo inicialmente pensado para teléfonos móviles, al igual que iOS,
Symbian y Blackberry OS. Lo que lo hace diferente es que está basado en Linux, un núcleo de
sistema operativo libre, gratuito y multiplataforma.

El sistema permite programar aplicaciones en una variación de Java llamada Dalvik. El sistema
operativo proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a
las funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla
en un lenguaje de programación muy conocido como es Java

ARQUITECTURA DE ANDROID
Kernel de Linux

La base de la plataforma Android es el kernel de Linux. Por ejemplo, el tiempo de ejecución de

Android (ART) se basa en el kernel de Linux para funcionalidades subyacentes, como la generación
de subprocesos y la administración de memoria de bajo nivel.

El uso del kernel de Linux permite que Android aproveche funciones de seguridad claves y, al
mismo tiempo, permite a los fabricantes de dispositivos desarrollar controladores de hardware
para un kernel conocido.

Capa de abstracción de hardware (HAL)

La capa de abstracción de hardware (HAL) brinda interfaces estándares que exponen las
capacidades de hardware del dispositivo al framework de la API de Java de nivel más alto. La HAL
consiste en varios módulos de biblioteca y cada uno de estos implementa una interfaz para un tipo
específico de componente de hardware, como el módulo de la cámara o de bluetooth. Cuando el
framework de una API realiza una llamada para acceder a hardware del dispositivo, el sistema
Android carga el módulo de biblioteca para el componente de hardware en cuestión.

Tiempo de ejecución de Android

Para los dispositivos con Android 5.0 (nivel de API 21) o versiones posteriores, cada app ejecuta
sus propios procesos con sus propias instancias del runtime de Android, ART. El ART está escrito
para ejecutar varias máquinas virtuales en dispositivos de memoria baja ejecutando archivos DEX,
un formato de código de bytes diseñado especialmente para Android y optimizado para ocupar un
espacio de memoria mínimo. Crea cadenas de herramientas, como Jack, y compila fuentes de Java
en código de bytes DEX que se pueden ejecutar en la plataforma Android.

Estas son algunas de las funciones principales del ART:

compilación ahead-of-time (AOT) y just-in-time (JIT)

recolección de elementos no usados (GC) optimizada

mejor compatibilidad con la depuración, como un generador de perfiles de muestras dedicado,

excepciones de diagnóstico detalladas e informes de fallos, y la capacidad de establecer puntos de
control para controlar campos específicos.

Antes de Android 5 (nivel de API 21), el runtime se llamaba Dalvik y tenía muchas carencias. En
Android también se incluye un conjunto de bibliotecas de tiempo de ejecución centrales que
proporcionan la mayor parte de la funcionalidad del lenguaje de programación Java; se incluyen
algunas funciones de Java 8.
Bibliotecas C/C++ nativas

Muchos componentes y servicios centrales del sistema Android, como el ART y la HAL, se basan en
código nativo que requiere bibliotecas nativas escritas en C y C++. La plataforma Android
proporciona la API del framework de Java para exponer la funcionalidad de algunas de estas
bibliotecas nativas a las apps. Por ejemplo, puedes acceder a OpenGL ES a través de la API de Java
OpenGL del framework de Android para agregar a tu app compatibilidad con los dibujos y la
manipulación de gráficos 2D y 3D.

Si desarrollas una app que requiere C o C++, se puede usar el NDK de Android para acceder a
algunas de estas bibliotecas de plataformas nativas directamente desde tu código nativo.

Framework de la API de Java

Todo el conjunto de funciones del SO Android está disponible mediante API escritas en el lenguaje
Java. Estas API son los cimientos que se necesitan para crear apps de Android simplificando la
reutilización de componentes del sistema y servicios centrales y modulares.

Los desarrolladores tienen acceso total a las mismas API del framework que usan las apps del
sistema Android.

Apps del sistema

En Android se incluye un conjunto de apps centrales para correo electrónico, mensajería SMS,
calendarios, navegación en Internet y contactos, entre otros elementos. Las apps incluidas en la
plataforma no tienen un estado especial entre las apps que el usuario elije instalar; por ello, una
app externa se puede convertir en el navegador web, el sistema de mensajería SMS o, incluso, el
teclado predeterminado del usuario (existen algunas excepciones, como la app Settings del
sistema).

Las apps del sistema funcionan como apps para los usuarios y brindan capacidades claves a las
cuales los desarrolladores pueden acceder desde sus propias apps. Por ejemplo, si en tu app se
intenta entregar un mensaje SMS, no es necesario que compiles esa funcionalidad tú mismo;
como alternativa, puedes invocar la app de SMS que ya está instalada para entregar un mensaje al
receptor que especifiques.
 COMPONENTES DE UNA APLICACIÓN ANDROID
Activity

Las actividades (activity) representan el componente principal de la interfaz gráfica de una

aplicación Android. Se puede pensar en una actividad como el elemento análogo a una ventana o
pantalla en cualquier otro lenguaje visual.

View

Las vistas (view) son los componentes básicos con los que se construye la interfaz gráfica de la
aplicación, análogo por ejemplo a los controles de Java o .NET. De inicio, Android pone a nuestra
disposición una gran cantidad de controles básicos, como cuadros de texto, botones, listas
desplegables o imágenes, aunque también existe la posibilidad de extender la funcionalidad de
estos controles básicos o crear nuestros propios controles personalizados.

Fragment

Los fragmentos (fragment) se pueden entender como secciones o partes (habitualmente

reutilizables) de la interfaz de usuario de una aplicación. De esta forma, una actividad podría
contener varios fragmentos para formar la interfaz completa de la aplicación, y adicionalmente
estos fragmentos se podrían reutilizar en distintas actividades o partes de la aplicación. No es
obligatorio utilizar fragmentos en una aplicación, pero sí nos serán de mucha ayuda en ciertas
ocasiones, por ejemplo para adaptar la interfaz de nuestra aplicación a distintos dispositivos,
tamaños de pantalla, orientación, etc.

Service

Los servicios (service) son componentes sin interfaz gráfica que se ejecutan en segundo plano.
Conceptualmente, son similares a los servicios presentes en cualquier otro sistema operativo. Los
servicios pueden realizar cualquier tipo de acción, por ejemplo actualizar datos, lanzar
notificaciones, o incluso mostrar elementos visuales (p.ej. actividades) si se necesita en algún
momento la interacción con del usuario.

Content Provider

Un proveedor de contenidos (content provider) es el mecanismo que se ha definido en Android

para compartir datos entre aplicaciones. Mediante estos componentes es posible compartir
determinados datos de nuestra aplicación sin mostrar detalles sobre su almacenamiento interno,
su estructura, o su implementación. De la misma forma, nuestra aplicación podrá acceder a los
datos de otra a través de los content provider que ésta última haya definido.

Broadcast Receiver

Un broadcast receiver es un componente destinado a detectar y reaccionar ante determinados

mensajes o eventos globales generados por el sistema (por ejemplo: “Batería baja”, “SMS
recibido”, “Tarjeta SD insertada”, …) o por otras aplicaciones (cualquier aplicación puede generar
mensajes (intents, en terminología Android) de tipo broadcast, es decir, no dirigidos a una
aplicación concreta sino a cualquiera que quiera escucharlo).
Widget

Los widgets son elementos visuales, normalmente interactivos, que pueden mostrarse en la
pantalla principal (home screen) del dispositivo Android y recibir actualizaciones periódicas.
Permiten mostrar información de la aplicación al usuario directamente sobre la pantalla principal.

Intent

Un intent es el elemento básico de comunicación entre los distintos componentes Android que
hemos descrito anteriormente. Se pueden entender como los mensajes o peticiones que son
enviados entre los distintos componentes de una aplicación o entre distintas aplicaciones.
Mediante un intent se puede mostrar una actividad desde cualquier otra, iniciar un servicio, enviar
un mensaje broadcast, iniciar otra aplicación, etc.

VERSIONES DE ANDROID

Nombre en Número Nivel

Fecha de
Nombre clave de de Referencias
lanzamiento
interno versión API

23 de 1
Android 1.0 1.0 1
septiembre de 2008

Android 1.1 Petit Four 1.1 9 de febrero de 2009 2

3 de 3
Android 10 Quince Tart 10.0 29
septiembre de 2019

Red Velvet 8 de 4
Android 11 11.0 30
Cake septiembre de 2020

5
Android 12 Snow Cone 12.0 - 12L 4 de octubre de 2021 31 - 32

6
Android 13 Tiramisú 13.0 15 de agosto de 2022 33

Upside Down 7
Android 14 14 DP1 8 de febrero de 2023 34
Cake
 Nombre en Número Nivel
Fecha de
Nombre clave de de Referencias
lanzamiento
interno versión API

Android
Cupcake 1.5 25 de abril de 2009 3
Cupcake

15 de
Android Donut Donut 1.6 4
septiembre de 2009

26 de
Android Eclair Eclair 2.0 – 2.1 5–7
octubre de 2009

Android Froyo Froyo 2.2 – 2.2.3 20 de mayo de 2010 8

Android 6 de
Gingerbread 2.3 – 2.3.7 9 – 10
Gingerbread diciembre de 2010

Android 22 de 2
Panal 3.0 – 3.2.6 11 – 13
Honeycomb febrero de 2011

Android Ice
Sandwich de 18 de
Cream 4.0 – 4.0.5 14 – 15
Helado octubre de 2011
Sandwich

Android Jelly
Jelly Bean 4.1 – 4.3.1 9 de julio de 2012 16 – 18
Bean

31 de
Android KitKat Key Lime Pie 4.4 – 4.4.4 19 – 20
octubre de 2013

Android Lemon 12 de
5.0 – 5.1.1 21 – 22
Lollipop Meringue Pie noviembre de 2014
 Nombre en Número Nivel
Fecha de
Nombre clave de de Referencias
lanzamiento
interno versión API

Android Macadamia
6.0 – 6.0.1 5 de octubre de 2015 23
Marshmallow Nut Cookie

New York
Android Nougat 7.0 – 7.1.2 15 de junio de 2016 24 – 25
Cheesecake

Oatmeal
Android Oreo 8.0 – 8.1 21 de agosto de 2017 26 – 27
Cookie

Pistachio Ice 6 de
Android Pie 9.0 28
Cream agosto de 2018

METODOLOGIAS DE DESARROLLO PARA UNA APLICACIÓN

Categorías del desarrollo de aplicaciones

La mayoría de las metodologías de desarrollo de aplicaciones se pueden agrupar en una de tres

categorías:

• Waterfall
• RAD
• Agile
• Waterfall

Las palabras clave para el método waterfall, o desarrollo de cascada de aplicaciones, son
planificación y secuencia. Todo el proyecto se traza en las etapas de planificación y análisis. El
cliente llega con una lista muy explícita de características y funcionalidades para la aplicación.
Luego, un gerente de proyecto toma todo el proceso y lo mapea entre el equipo.

Este método de desarrollo de aplicaciones se llama cascada porque una vez que bajas, no puedes
volver a subir; todo fluye hacia abajo. El equipo de desarrollo trabaja en conjunto durante un
período de tiempo, construyendo exactamente lo que está diseñado de acuerdo con las
especificaciones. Una vez diseñada la arquitectura, solo entonces puedes comenzar la
construcción. Se crea toda la aplicación y luego se prueba para asegurarse de que funciona
correctamente. Luego, se muestra al cliente y está listo para ser implementado.
El método de cascada asume que los requisitos del proyecto son claros y que el cliente y el
director del proyecto tienen una visión unificada y clara sobre el resultado final.

La ventaja del método de cascada es que es muy meticuloso. También es un buen método de
desarrollo de aplicaciones para grandes proyectos que necesitan tener una visión unificadora. El
método de cascada también es una buena manera de capacitar a los programadores junior en
partes del desarrollo sin tener que entregarles un proyecto completo.

Las desventajas son que los cambios ocurren todo el tiempo. Incluso si el equipo de desarrollo
puede construir exactamente lo que el cliente quería originalmente (lo que no siempre sucede), el
mercado, la tecnología o la organización pueden haber cambiado tanto que es inútil y una pérdida
de tiempo.

Waterfall funciona mejor como método de desarrollo de aplicaciones cuando:

Se fijan presupuestos para el proyecto.

Has hecho un proyecto similar antes

El cliente es muy claro y no piensa involucrarse mucho hasta el final.

Rapid Application Development (RAD)

Como te puedes imaginar, el método de desarrollo de aplicaciones en cascada presentó algunos

problemas importantes. El proceso de desarrollo a menudo tomaba mucho tiempo para ver un
producto que funcionara, los equipos tenían que ser grandes para adaptarse a todos los requisitos
y las tensiones aumentaban cuando un cliente no estaba satisfecho con el producto final y todo el
proyecto tenía que empezar de nuevo desde el principio.

Entonces, surgió un nuevo método llamado desarrollo rápido de aplicaciones (RAD). En muchos
sentidos, RAD era lo opuesto al método de cascada.

RAD se basa principalmente en prototipos, lo que significa que el objetivo es producir una versión
funcional de la aplicación lo más rápido posible y luego iterar continuamente después de eso. El
equipo de desarrollo de la aplicación y el cliente trabajan en estrecha colaboración durante todo el
proceso. Los equipos de RAD suelen ser pequeños y solo involucran a desarrolladores
experimentados que son expertos en muchas disciplinas. Si un proyecto necesita desviarse del
plan original, RAD debería poder adaptarse fácilmente.

Ventajas de metodología RAD

En el modelo RAD, a medida que se completa cada iteración, el producto se vuelve más y más
refinado. Los primeros prototipos suelen ser muy toscos, pero dan una idea de lo que puede ser.
Luego, cada iteración se parece más al producto terminado.

Las ventajas de RAD son un equipo rápido y muy flexible y una relación muy estrecha con el
cliente. Si se esperan cambios, RAD podrá acomodarlos mucho más rápido que en el método
waterfall. RAD nunca está demasiado apegado a un prototipo y siempre está dispuesto a
cambiarlo para adaptarlo a las necesidades del cliente.
Sin embargo, RAD no es un método de desarrollo de aplicaciones perfecto. RAD requiere
programadores altamente calificados (y muy bien pagados) para trabajar en un proyecto que
puede cambiar en complejidad día a día. También hay menos cumplimiento de los plazos y más
enfoque en agregar funciones, lo que puede extender las fechas de entrega. RAD requiere una
gran cantidad de información de los clientes que pueden no estar siempre disponibles o saber lo
que necesitan. Además, para algunas aplicaciones, tener un prototipo no es útil sin ver el producto
completo.

RAD es un gran método de desarrollo de aplicaciones para:

Un experimentado equipo de desarrolladores.

Un cliente muy comprometido

Una fecha de entrega flexible

Un negocio apremiante

Metodología Agile

El desarrollo de aplicaciones Agile es muy similar a RAD, pero también incluye algunos cambios
para que sea más adecuado para proyectos más grandes. Agile es iterativo, como RAD, pero se
enfoca en crear características una a la vez. Cada función se crea de manera metódica en el
equipo, pero el cliente está involucrado para ver las funciones y aprobarlas antes de que se
desarrolle la siguiente función.

Agile utiliza sprints, o conjuntos de tiempo en los que se debe construir, probar y presentar una
característica determinada. Intenta incorporar todo el SDLC para una característica en cada sprint.
Idealmente, esto ayuda a cumplir con un cronograma planificado, pero también permite revisiones
frecuentes.

Agile no se enfoca en prototipos, sino que solo presenta el trabajo completado después de que
finaliza el sprint. Por lo tanto, si bien se informa al cliente con más frecuencia que en cascada, el
cliente solo ve el trabajo terminado, a diferencia de RAD.

La metodología ágil de gestión de proyectos también se basa más en equipos o escuadrones. Con
RAD, está trabajando directamente con un programador. Con Agile, el equipo de desarrollo de
aplicaciones también incluirá evaluadores, diseñadores de UX, escritores técnicos y muchos otros.

Agile es una excelente metodología de desarrollo de aplicaciones cuando:

El proyecto es lo suficientemente grande como para dividirse en varios sprints.

Tienes muchos especialistas que pueden trabajar juntos en un equipo.

La mayor parte del proyecto se conoce con anticipación y se puede planificar

CICLO DE VIDA DE UNA APLICACIÓN

Cuando se habla del ciclo de vida de desarrollo de software se hace referencia al proceso utilizado
para diseñar, desarrollar y probar un software o aplicación móvil. El objetivo último es el de crear
un producto de alta calidad que cumpla o supere las expectativas de los clientes. Pero no sólo eso.

El proceso debe finalizarse cumpliendo el tiempo y los costes estimados al inicio. No se trata de
simple y llanamente crear una aplicación, sino crearla de manera exitosa. Ahí está el quid de la
cuestión.

El ciclo de vida del desarrollo de software está compuesto por las fases de planificación,
requerimientos técnicos, prototipado, desarrollo, QA o testing y publicación y mantenimiento.
Vamos a ver más a fondo en qué consiste cada una de ellas y qué profesionales están implicados.

Planificación

En esta fase trabajan conjuntamente diferentes perfiles profesionales para definir bien qué se
necesita y cómo se va a desarrollar el proyecto: project manager, marketing, analista de negocios
etc.

Se trata de evaluar cuál es la idea de negocio, el fin de la aplicación, pero también es el momento
de definir a qué audiencia se dirigirá. Entender quién es tu target es crucial para enfocar la
estrategia posterior de lanzamiento, pero también para otros aspectos como el diseño UI, por
nombrar algunos ejemplos.

También es la hora de realizar un estudio de la competencia y un análisis DAFO. Con toda la

información recopilada es hora de tomar la decisión de en qué plataformas estará disponible, cuál
será la estrategia de adquisición y retención de usuarios, y la estrategia de monetización.

Requerimientos técnicos

En esta fase se definen las especificaciones técnicas que debe cumplir la aplicación. Con la
documentación del software se detallan todos los requisitos del proyecto, el enfoque comercial
y sirve de guía para todos los profesionales implicados en las distintas fases del proyecto.

Prototipado

Esta fase suele corresponder a un diseñador UX/UI, que es el responsable de crear los esbozos,
wireframes, prototipos y la imagen gráfica final de la aplicación.

Se trata de definir paso a paso cómo será la apariencia pero también la navegación por la app.
Desde los primeros esbozos en papel, al wireframe y, posteriormente un prototipo navegable que
simule cómo será el uso. De esta manera escalonada es posible analizar todos los posibles casos
de uso, detectar si hay algún tipo de inconsistencia o error en la idea original y corregirlo.

DISIPLINAS DE UN PROCESO RUP

Para el RUP, las disciplinas son actividades en secuencia parcialmente ordenadas, relacionadas con
un área de atención dentro de un proyecto de software, para lograr un resultado. Son una ayuda
para entender el proyecto desde la perspectiva de cascada.

• Modelado de Negocios
1. Medir el impacto del cambio organizacional.
2. Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan un
entendimiento compartido del problema.
3. Derivar los requerimientos del sistema de software, necesarios para dar soporte a los
objetivos de la organización.
4. Entender como el sistema a ser desarrollado entra dentro de la organización.

• Requerimientos
1. Proveer a los desarrolladores del sistema de un mejor entendimiento de los
requerimientos del sistema.
2. Definir los límites (o delimitar) del sistema.
3. Proveer un base para la planeación de los contenidos técnicos de las iteraciones.
 4. Proveer una base para la estimación de costo y tiempo necesarios para desarrollar el
sistema.
5. Definir una interfaz de usuario para el sistema, enfocada en las necesidades y
objetivos del usuario.

Análisis y Diseño

1. Transformar los requerimientos a diseños del sistema.

2. Desarrollar una arquitectura robusta para el sistema.
3. Adaptar el diseño para hacerlo corresponder con el ambiente de implementación y
ajustarla para un desempeño esperado.

• Implementación
1. Definir la organización del código, en términos de la implementación de los subsistemas
organizados en capas.
2. Implementar el diseño de elementos en términos de los elementos (archivos fuente,
binarios, ejecutables y otros)
3. Probar los componentes desarrollados como unidades.
4. Integrar los resultados individuales en un sistema ejecutable.

• Pruebas
1. Encontrar fallas de calidad en el software y documentarlas.
2. Recomendar sobre la calidad percibida en el software.
3. Validar y probar las suposiciones hechas durante el diseño y la especificación de
requerimientos de forma concreta.
4. Validar que el software trabaja como fue diseñado.
5. Validar que los requerimientos son implementados apropiadamente.

• Transición

Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y

disponibilidad del producto de software hacia el usuario final.

• Administración y Configuración del Cambio

1. Identificar los elementos configurables.
2. Restringir los cambios en los elementos configurables.
3. Auditar los cambios hechos a estos elementos.
4. Definir y mantener las configuraciones de estos elementos.
5. Los métodos, procesos y herramientas usadas para proveer la administración y
configuración del cambio pueden ser consideradas como el sistema de administración de
la configuración.
 • Administración de Proyectos
1. Proveer un marco de trabajo para administrar los proyectos intensivos de software.
2. Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos.
3. Proveer un marco de trabajo para la administración del riesgo.

• Ambiente
1. Se enfoca en las actividades necesarias para configurar el proceso al proyecto.
2. Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto.
3. El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo
de software del ambiente necesario (herramientas y procesos) que den soporte al equipo
de desarrollo.

METODOLOGIA XP (EXTREME PROGRAMMING)

La metodología XP o Extreme Programming corresponde a una metodología de desarrollo
perteneciente a las metodologías ágiles, su objetivo es desarrollar y gestionar proyectos con
eficiencia, flexibilidad y control, se basa en la comunicación, reutilización del código desarrollado y
realimentación.

• Características

Las características de la metodología XP para el desarrollo de software son 5:

1. Comunicación frecuente cliente/equipo de desarrollo.

2. Respuesta rápida a los cambios frecuentes.
3. Planificación abierta con cronograma de actividades flexible.
4. Software que funciona superpone cualquier otra documentación.
5. Requisitos del cliente y trabajo del equipo del proyecto son factores prioritarios para el
éxito del mismo.

• Fases de la metodología de programación extrema

Las fases de la metodología de programación extrema o XP se basan en 5 pasos, estos son:

1. Planificación: va de acuerdo con las historias de usuario, estas se priorizan y descomponen

en mini versiones, luego la planificación se va revisando cada dos semanas
aproximadamente, después de las iteraciones, para obtener un software útil, funcional,
listo para las pruebas y su lanzamiento.
 2. Diseño: se trabaja con un código sencillo, realizando lo mínimo necesario para que
funcione, se obtiene el prototipo. Luego para el diseño del software si va orientado a
objetos se generan tarjetas CRC (Clase-Responsabilidad-Colaboración).
3. Codificación: se hace a dos manos, es decir en parejas frente al mismo ordenador, en
algunos casos se intercambian las parejas, para asegurar que el código sea más universal,
de forma que cualquier otro trabajador pueda trabajar en el y entenderlo. Debe parecer
que fue hecho por una sola persona, para que se obtenga una programación organizada y
planificada.
4. Pruebas: deben ser automáticas y continuas, esto es clave para proyectos a corto plazo.
Incluso el mismo cliente puede hacer pruebas, proponer pruebas nuevas y validar las mini
versiones.
5. Lanzamiento: si se llega a este punto es porque se han probado todas las historias de
usuario o mini versiones y han tenido éxito, ajustándose a los requerimientos del cliente.
Generando un software útil y que puede incorporarse en el producto.

• Valores de la metodología Xp

La metodología XP es desarrollada en base a cinco valores fundamentales, cuyo objetivo

fundamental es que el equipo de desarrolladores trabaje con la mentalidad conjunta para
colaborar y crear un producto de alta calidad, dichos valores son:

1. Simplicidad: la clave de la programación XP siempre será comenzar por la solución más

simple, codificar las necesidades de hoy, no las futuras. Se simplifica el diseño para agilizar
el desarrollo y que sea sencillo el mantenimiento. Para que se conserve la simplicidad se
debe mantener la refactorización del código, para así preservar el código simple a medida
que crezca.
2. Comunicación: se refiere a la buena interacción interna entre los miembros del equipo de
desarrolladores y con los clientes. Su objetivo es romper las barreras entre negocio y
desarrollo, para ello promueve que todos los requisitos sean comunicados y trabajados en
equipo y no a través de documentación.
3. Feedback: al integrar al cliente en el proyecto se puede tener su opinión sobre el estado
de este en tiempo real. Los ciclos cortos de presentación de resultados permiten
minimizar el riesgo de tener que hacer nuevamente partes que no cumplen con las
expectativas del cliente y ayuda a los programadores a centrarse en las tareas
importantes.
4. Respeto: importante para que el equipo trabaje eficientemente y de buen rendimiento, va
desde que un desarrollador no haga cambios que afecten negativamente el trabajo de un
compañero hasta la forma en que se llega al cliente. Se manifiesta el respecto en varias
formas, todas importantes para mejor autoestima del equipo que lleva el mayor ritmo de
trabajo.
5. Valentía: se tiene cuando se diseña un programa para hoy y no se deja para mañana, al
igual que reconocer los errores a penas se detectan. Nadie en el equipo puede intentar
 minimizar su responsabilidad en un error cometido, pues esto implica que se deja de
centrar en otras cosas e impide que avance el resto, bajando la productividad.
• Aplicación de la metodología

Un proyecto de desarrollo de software se aplica de forma efectiva y ágil cuando se adapta a los
cambios frecuentes y al ritmo de trabajo dinámico, para ello se debe contar con herramientas
digitales que le permitan al coach llevar las siguientes actividades:

1. Organizar reuniones diarias.

2. Armar listados de tareas.
3. Realizar trabajos colaborativos de remotamente.
4. Controlar los adelantos.
5. Notificar a los miembros del equipo y mantener comunicación efectiva.

• El equipo en la metodología XP
• Las funciones en un equipo que trabajo con la metodología XP son las que listamos a
continuación:

1. Clientes: crean prioridades y marcan el proyecto, son los usuarios finales del producto y
quienes indican las necesidades.
2. Programadores: se encargarán de desarrollar el Extreme Programming.
3. Testers: encargados de ayudar al cliente con los requisitos del producto.
4. Coach: aconsejan a los demás integrantes del equipo y marcan la dirección del proyecto.
5. Manager: dan recursos, responsable de la comunicación externa y coordinar las
actividades.

PROCESO XP

“Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado
en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El
ciclo de desarrollo consiste en los siguientes pasos:”

1. El cliente define el valor de negocio a implementar.

2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe
presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el
software o no se cumplirán los plazos.

FASES DE DESARROLLO DE LA PROGRAMACIÓN EXTREMA

El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega, Iteraciones,
Producción, Mantenimiento y Muerte del Proyecto.

“Fase I: Exploración: En esta fase, los clientes plantean a grandes rasgos las historias de usuario
que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo
se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se
prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un
prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño
y familiaridad que tengan los programadores con la tecnología.

Fase II Planificación de la Entrega: En esta fase el cliente establece la prioridad de cada historia de
usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de
tres meses. Esta fase dura unos pocos días. La planificación se puede realizar basándose en el tiempo
o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden
implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto
de historias.

Fase III Iteraciones: Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración
se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto
del proyecto. Al final de la última iteración el sistema estará listo para entrar en producción.

Fase IV: Producción: La fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se
deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a
cambios durante esta fase. Las ideas que han sido propuestas y las sugerencias son documentadas
para su posterior implementación (por ejemplo, durante la fase de mantenimiento).

Fase V: Mantenimiento: Mientras la primera versión se encuentra en producción, el proyecto XP

debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.
Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de
desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento
puede requerir nuevo personal dentro del equipo y cambios en su estructura.

Fase VI: Muerte del Proyecto: Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se
realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema
no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo”.

ANALISIS COMPARATIVO

Los sistemas operativos móviles son los encargados de la gestión del hardware y software y de la
interacción con el usuario final en un dispositivo celular, Tablet, etc. Se presenta a continuación un
análisis comparativo de algunos sistemas operativos móviles. Se incluyen a éstos como son
Android, y Windows 10 Mobile. Este análisis comparativo comprende el desarrollo de las
diferencias entre los sistemas operativos mencionados anteriormente de manera imparcial desde
diferentes puntos de vistas y aspectos tanto técnicos, de seguridad y usabilidad.

DESCRIPCION DE MATADOLOGIA SELECCIONADA

No existe una metodología universal para aplicarla con éxito a cualquier proyecto de desarrollo de
software. Toda metodología debe ser adaptada a todo el contexto del proyecto como son:
recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Sin embargo, la
Programación Extrema proporciona una serie de ventajas para la realización del proyecto ya que
ayudan al ahorro de tiempo y recursos.

Permite la entrega de productos usables con mayor rapidez lo que permite la entrega de
versiones continuas al usuario.
Presenta un código más simple y fácil de entender que permite la reducción del número de
errores en su desarrollo.

Capacidad de respuesta ante cambios permitiendo la adaptación a nuevos requisitos de la

empresa u organización. Por estas y muchas otras ventajas es la Metodología que más se adecua a
nuestro proyecto de desarrollo ya que pertenece a las “Metodologías Agiles de Desarrollo” y como
su nombre lo indica nos agiliza su desarrollo.