Proyecto, Profe Pablo
Proyecto, Profe Pablo
ESTADO DE MEXICO
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.
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
Objetivo
Desarrollar una aplicación para dispositivos móviles plataforma Android que permita
agendar números telefónicos
Objetivos específicos
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).
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
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.
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.
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.
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.
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.
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
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
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
Broadcast Receiver
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
23 de 1
Android 1.0 1.0 1
septiembre de 2008
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 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
• 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.
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.
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.
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.
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.
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.
• 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
• 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
• 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.
• Características
• Valores de la metodología Xp
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:
• 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:”
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 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.
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.