Examen analista de desarrollo de software

Definiciones:


Software:
Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la función y el rendimiento deseados

Ingeniería Software


Aplicación de teorías, métodos, herramientas para hacer cosas que funcionen (planificar, diseñar, reutilizar)

HerramientasCASE:Software que facilita la realización de actividades del proceso de desarrollo de software


Upper-CASE(herramientas captura de requisitos,análisis y diseño)


Lower-CASE


(herramientas programación, depuración, pruebas).


Ingeniería Sistemas:aspectos del desarrollo de sistemas basados en computadora, tanto del hardware como del software y los procesos de diseño y distribución de sistemas.
Costes de la IS:desarrollo, mantenimiento y evolución, Varia dependiendo:tipo de sistema que se desarrolle, modelo de desarrollo, 60% desarrollo, 40%pruebas.

Artefacto


: Un artefacto es cualquier elemento relacionado con el proyecto (documentación, diseños, programas, etc).


Retos IS:Sistemas heredados (mantenimiento, actualización), heterogeneidad (SW y HW) de sistemas distribuidos, tiempos de desarrollo cada vez mas
cortos, modas (métodos, lenguajes), cultura de ingeniería, formalidad. Producto: software:cada día + caro, + grande, – eficiente, – robusto.

Carácterísticas


el sw se desarrolla no se fabrica, los costes se centran en ingeniería, no en fabricación, el sw no se estropea, hay que mantenerlo, la reparación puede dañarlo mas.

Atributos:mantenible, seguro, robusto, eficiente, amistoso, bien documentado


Tipos


de sistemas,de gestión, de pc, de ingeniería, científico, empotrado, ia, móviles.


Responsabilidad y ética profesional:confidencialidad, competencia derechos de propiedad, intelectual (patentes, copyright), mal uso de los sistemas.

Hardware


cada día + barato, + pequeño, + eficiente, + robusto.


Modelos de proceso
:PDP)Unificado de Desarrollo. Es un modelo dirigido por casos de uso, iterativo e incremental.Iterativose refiere a los pasos en el flujo de trabajo e incrementalal crecimiento del producto.
En cada iteración se iteran cuatro fases: inicio(descripción del producto final) , elaboración (especifican los cdus, diseño arquitectura del sistema), construcción (se crea el producto) ytransición (periodo durante el cual el producto se entrega a los clientes). En estas iteraciones se llevan a cabo las tareas de identificar requisitos
de usuario, análisis, diseño, implementación y pruebas. Si una iteración cumple sus metas el desarrollo continúa con la siguiente iteración.
CDUutilizamos el Lenguaje de Modelado Unificado (UML), tienen particular importancia en el Proceso Unificado ya que se utilizan para capturarlos requisitos funcionales.

Ventajas


de este modelo de proceso es que es un modelo racional. Proporciona un enfoque riguroso en el reparto de tareas y responsabilidades dentro del equipo de desarrollo. Utiliza tecnologías de componentes, es decir, que el sistema está compuesto de
componentes software interconectados por medio de interfaces. Asegura un producto software de alta calidad y que satisfaga todos los requerimientos del usuario final, en unas fechas de entrega y con un coste estimable de forma precisa.
Inconvenientes:que está muy ligado al método, y está metodología es bastante compleja. Es difícil aprender cómo funciona el proceso y cómo aplicarlo correctamente al proyecto, requiriendo de un equipo de desarrollo con experiencia en el uso de este modelo de proceso o que tenga en cuenta es esfuerzo adicionalnecesario para estudiarlo.

Otros modelos de proceso:Modelo en cascada

(Buena visibilidad). Separa en distintas fases de especificación y desarrollo que se realizan en secuencia lineal. Pasa a

Través de una serie de fases, al final se revisan las tareas para poder pasar a la sig fase, fácil de entender


Fases:Conceptualización, Análisis de

Requisitos, Diseño, Implementación, Prueba, Instalación y comprobación


Variantes:Modelo sashimi, Summerville, Pressman, modelo en V,

Cascada con subproyectos


Ventajas:Muy probado, sencillo

Inconvenientes:Poco realista, supone una especificación de requisitos estable, baja

visibilidad, un error grave en las últimas fases puede ser letal . Si no hay solapamientos entre fases puede haber bloqueos . Las revisiones de proyectos de gran complejidad son muy difíciles.Prototipado: Comienza con la recolección de requisitos (clientes y desarrolladores definen los objetivos globales), Diseño rápido centrado en los aspectos visibles, el prototipo lo evalúa el cliente y lo utiliza para refinar los requisitos, el proceso se itera desechando el primer prototipo. Ventajas:Permite identificar los requisitos incrementalmente, permite probar alternativas a los desarrolladores, tiene una alta visibilidad (se ven resultados rápidamente).
Inconvenientes:El cliente no entiende por que hay que desechar el primer prototipo, riesgo de software de baja calidad (ej, utilizar un s.O. O lenguaje de baja calidad).
Desarrollo evolutivo (Visibilidad pobre) – La especificación y el desarrollo están intercalados, gestionan bien la naturaleza evolutiva del software,son iterativos (construyen versiones del software cada vez mas completas), se adaptan bien a: los cambios del requisito del producto, fechas de entrega estrictas poco realistas, especificaciones parciales del producto.
Modelo evolutivo incremental:Cada secuencia lineal produce un incremento del software, ventajas:es iterativo, personal, gestión de riesgos técnicos,

Inconvenientes:puede plantear los mismos problemas queun modelo lineal secuencial


Diferencias entre modelo evolutivo incremental vs prototipo:


Se diferencia del modelo por prototipos en que en prototipos se da por hecho que aunque se necesiten varias iteraciones para lograrlo al final se llegará a tener una serie de requisitos completos y
sin errores, que no vayan a cambiar más.En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de

Vida y no solo en la etapa de análisis


Modelo evolutivo en espiral:(Buena visibilidad) Se centra en tratar las áreas de mayor riesgo en unproyecto, el proyecto se compone de varios mini-proyectos que tratan una o varias áreas de riesgo, múltiples iteraciones sobre varias regiones de tareas.
Ventajas:enfoque realista, gestión explícita de riesgos, reutilización de componentes y la eliminación de errores en información fases

Iniciales, integra desarrollo con mantenimiento


Inconvenientes:Convencer cliente enfoque controlable, requiere experiencia en la identificaciónde riesgos. Ejemplos procesos evolutivos modernos: modelos pesados (proceso unificado), modelos ágiles (eXtreme Programming, Scrum).
Modelos de proceso ágil: parten de 3 supuestos clave:difícil predecir qué requisitos software persistirán y cuáles cambiarán, diseño y el desarrollo de software están intercalados, análisis el diseño y la construcción no son predecibles desde el punto de vista de la planificación.
Carácterísticas:Es adaptable de forma incremental, necesita retroalimentación del cliente, se basa en la entrega continua de incrementos. La

Agilidad se puede aplicar a cualquier proceso de software


eXtreme Programming (XP):Un modo ligero, eficiente, de bajo riesgo, flexible,predecible, científico y divertido de producir software.
Carácterísticas:Alta visibilidad debido a ciclos muy cortos, planificación incremental, seadapta a cambios de negocio.
Claves:Basado en pruebas automatizadas escritas por desarrolladores y clientes , alta comunicación , diseño evolutivo , colaboración entre programadores , busca equilibrio entre las necesidades a corto plazo de los programadores y las de largo plazo del

Proyecto


Estructura:codificación -> prueba -> evaluación -> diseño


Prácticas:juego de planificación , pequeñas entregas, metáfora , diseño simple , prueba , refactorización, programación en pareja, propiedad colectiva , integración continua , semana de cuarenta horas , cliente en el lugar de desarrollo, codificación estándar.

Ventajas:Bueno para especificaciones cambiantes, fundamentación práctica


Inconvenientes:pocoprobado, poco compatible con especificaciones, solo funciona con equipos pequeños (10 personas)


Scrum:Se basa en:Equipos de trabajoorganizados para maximizar la comunicación y minimizar los gastos , proceso adaptable a cambios técnicos y de negocio para asegurar el mejor
producto , incrementos frecuentes de software , trabajo y equipo divididos en paquetes de bajo acoplamiento , capacidad de construir un producto cuando se requiera.  Actividades:requisitos, análisis, diseño, evolución, entrega. Patrones de proceso:Product backlog (trabajoacumulado) lista de requisitos priorizados que puede actualizarse en cualquier momento, salvo sprint. Sprint: Trabajo requerido para satisfacer un requisito definido (30 días normalmente).

Patrones de proceso:Reuníón diaria corta (15”) centrada en: ¿Qué hiciste desde la última reuníón?


¿Tienes algún obstáculo? ¿Qué harás antes de la próxima reuníón?


Transformación formal:(Buena visibilidad). Se basa en la transformación de una especificación formal a lo largo de varias representaciones hasta llegar a un programa ejecutable.
Problemas:Hace falta una formación especializada para aplicar la técnica, aspectos de los sistemas reales son difíciles de especificar formalmente (interfaz de usuario, requisitos no funcionales) Desarrollo basado en reutilización(Visibilidad moderada). El sistema es ensamblado a partir de componentes existentes. Un componente es una parte física y reemplazable de un sistema que se ajusta a, y proporciona la realización de, un conjunto de interfaces. Se modela y construye en base a componentes software interconectados a través de interfaces bien definidas.

Ventajas:componentes. Inconvenientes:tamañobiblioteca (como encontrar los componentes adecuados)


Requisitos:funcionales:describen:- Servicios que proporciona el sistema(funciones), – Respuesta del sistema ante determinadas entradas, -Comportamiento del sistema en situaciones particulares, – Determinan lo que no debería hacer el sistema (en algunos casos).

No funcionales:Restricciones de los servicios o funciones que ofrece el sistema


Ejemplos:El tiempo de proceso de una petición será siempreinferior a 1 segundo. El sistema de biblioteca debe ser capaz de atender simultáneamente a todas las bibliotecas de la universidad, estimadas enpicos de 50 peticiones/minuto.
Tipos:- Requisitos del producto (especifican el comportamiento del producto), Requisitos organizativos (estándares de proceso o lenguajes de programación), Requisitos externos (requisitos legislativos o éticos).
Estimaciones del proyecto: (PDP)El esfuerzo depende del número de integrantes del equipo y el tiempo que estos estén trabajando, midiéndose en PM (Personas-Mes). Calculando el esfuerzo es posible establecer el coste de desarrollo del proyecto.
Técnica de estimaciónusaremos la técnica basada en la descomposición del producto, usando Puntos de Función (PF) para medir el tamaño del software. Está técnica se basa en la descomposición del sistema para facilitar estimar su tamaño. Estimando usando los PFs el tamaño del software se estima basándose en su funcionalidad. No es necesario llegar al nivel de detalle requerido estimando Líneas de Código.
Análisis del riesgo: Identificamos los riesgos más probables, teniendo en cuenta el Top 10 Software
Risk ÍTEMS de Boehm y los riesgos que identifica Sommerville, agrupándolos por riesgos de planificación, personal, recursos y requisitos.
Consideraremos controlar sólo los riesgos por encima de la línea de corte, es decir los riesgos con un nivel de riesgo intolerable o alto.
Asignaremos a estos riesgos medidas de reducción, supervisión y gestión. Para los riesgos menos peligrosos propondremos alternativas a la reacción de los riesgos: evitarlos, controlarlos, asumirlos o transferirlos.
Planificación: Planificaciones y presupuestos poco realistas, Reparto no equitativo de tareas, Aplicación de cambios no notificados ni reflejadosen el control de cambiosPersonal Abandono del proyecto por un miembro del grupo, Deficiencias del personal, Desarrollo de funciones erróneas, Personal no disponibleen momentos críticos, Trabajo individual que no se integra con el resto del proyectoRecursos Problemas en el uso de herramientas CASE (Desconocimiento o falta de experiencia)Requisitos Cambios en requisitos (
modificación o eliminación de requisitos en el proyecto por un mayor entendimiento de cómo deberíafuncionar la aplicación al comenzar su desarrollo. Obligaría a la replanificación del proyecto y probablemente retrasaría la fecha de entrega final.)Especificación incompleta o incorrecta de requisitosEstructura de equipo :Se utilizará un modelo de organización según Mantei, en concreto el modelo descentralizado controlado(DC).Existen dos jefes de grupo,que se encargan de coordinar el trabajo de los integrantes del grupo y repartirlo en subgrupos, así como asegurar que el proyecto no se retrasa y estamos siguiendo en todo momento la planificación temporal establecida. Los diversos subgrupos tienen jefes secundarios responsables de las tareas asignadas a los subgrupos.Garantía de calidad:consiste en las funciones de información de la gestión. El objetivo es proporcionar gestión para informar de datosnecesarios sobre la calidad del producto,Garantía de control:revisiones y pruebas realizadas a lo largo del proceso del software para asegurar que cada producto cumple con losrequisitosEl principal objetivo de la Gestión de Cambioses la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo,se haga de la forma más eficiente, siguiendo los procedimientos establecidos.
Ventajas: reducir el número de incidentes y problemaspotencialmente asociados a todo cambio, poder retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga
un impacto negativo o reducir el número de «back-outs» necesarios.GCS: Gestión de Configuración del Software:Actividad de protección que gestiona el cambio en los artefactos (documentos, archivos,manuales código…) a lo largo del ciclo de vida del producto.
Tareas:Identificar el cambio, Controlar el cambio, Garantizar la correcta implementación del cambio, informar del cambio a todos aquellos que lo necesiten.
Para ello recurren a:Estándares, normas, procesos. ECS:Cada uno de los artefactos de la configuración se denomina Elemento de configuración de Software, estos ECS producen otros ECS para crearuna jerarquía de información en el proyecto.
Desafíos:Saber qué configuración es la que interesa para un cometido concreto, saber cuantas hay /ha habido, saber que se diferencian.
Gestión:Identifica y define los tipos de artefactos a gestionar (los ECSs), establecer criterios y protocolos para nombrar los ECS, define quien es el responsable de los procedimientos de GCS, define políticas para el control de cambios, define losregistros de GCS que deben mantenerse.
Gestión de equipos:Actividades:Redacción de la propuesta, estimación del coste producto, planificación del proyecto, revisiones, informes,control y organización personal.
Tipos de participantes:Gestores superiores (definen aspectos del negocio), Gestores (planifican, motivan,organizan), Profesionales (proporcionan capacidades técnicas), Clientes (especifican requisitos del proyecto), Usuarios finales (interactúan con elsoftware).
Estructuras de equipo de desarrollo:descentralizada democrático (DD)No tiene 1 jefe permanente, se nombra un jefe en función decada tarea, las decisiones, problemas se llevan a consenso del grupo, la comunicación entre los miembros del grupo es horizontal.
Descentralizado controlado (DC)tiene un jefe de equipo para las tareas, tiene jefes de equipo para subtareas, resolución de problemas engrupo, jefe de grupo distribuye la implementación de tareas entre los subgrupos, comunicación entre subgrupos e individuos es horizontal,comunicación vertical entre los jefes secundarios y el jefe de equipo.
Centralizado Controlado (CC)1 único jefe de equipo, éste resuelve losproblemas a alto nivel y coordinación de equipo, Comunicación vertical entre el jefe y los miembros del equipo.

Estructura:Mantei identifica 7

factores de un proyecto para determinar la estructura: Dificultad del problema, tamaño en líneas de código, duración del equipo, modularidad del
problema, calidad del sistema a construir, fecha de entrega, comunicación requerida en el proyecto. |||| A partir de 4 personas hace falta jefe, a
partir de 6 subjefes. Se requiere una coordinación y comunicación adecuada para atender a factores como: Escala, incertidumbre,interoperabilidad.
Gestión de proyectos:Abordar los problemas de fechas:Realizar estimaciones detalladas (recursos necesarios, disponibles), Utilizar modelos,incrementales (Implementar la funcionalidad crítica mínima anticipadamente), Establecer plazos realistas para ejecutar las tareas previstas,

Reunirse con los clientes para analizar y explicar el devenir del proyecto


Descomposición basada en el producto:partición horizontal: Sedescompone el sistema en módulos (agrupación de funciones que llevan a cabo tareas de naturaleza similar), partición vertical:se trata de unadescomposición hasta el nivel de funciones.

Regla del 40‐20‐40:40% análisis y diseño, 20% codificación, 40% pruebas


Conclusiones:Laplanificación del proyecto tiene como objetivo evitar retrasos, consiste en establecer tareas para llevar a cabo el proyecto y relacionarlas (fechainicio / fin, recursos, esfuerzo).

Estimación de costes:costes de hw y sw, de esfuerzo, viajes y formación, infraestructura en la organización


Esfuerzo de un proyecto:es lacantidad de trabajo a dedicar para desarrollar el proyecto (depende num personas y tiempo), Suele
medirseen Persona-Mes (PM), se midefuncionalidad útil x unidad tiempo. El esfuerzo se liga a unas tarifas para establecer el coste de desarrollo del proyecto. Se considera, 1 mes = 22

Días laborales, jornada completa 8h y media 4h


Técnicas de estimación:Malas: Retrasar la estimación lo máximo posible (+ retraso +precisa

será), Ley de Párkinson (El trabajo se extiende para llenar el tiempo posible), Precio para ganar (el coste se estima en todo el dinero que el cliente

Puede gastar en el proyecto)


Buenas:Estimación por analogía (Utilizar el coste de proyectos similares ya terminados), Técnicas de descomposición (Estiman el coste descomponiendo el producto), Modelos empíricos (Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad).
Descomposición basada en el producto:se basan en la descomposición de módulos o funciones, facilita estimar su tamaño,distintas formas de medir el software (Lineas de código, Puntos de función, Punto objeto), a + grande la función + precisión estimación.
Puntosde función:El tamaño del software se puede estimar basándose en su funcionalidad utilizando los PF o PO. Se parte de la descomposición del
problema pero sin llegar al nivel de detalle requerido para las LDC. Muy orientado a sistemas de gestión (BBDD). Descomposición basada en elproceso:Descomposición del problema en grandes bloques funcionales, Utilizando el proceso, identificar un conjunto pequeño de actividadesde trabajo o tareas de trabajo, Se estima el esfuerzo requerido para llevar a cabo cada tarea.
Proceso de estimación:Conveniente hacer varias,estimaciones del proyecto siguiendo varias técnicas, dando una estimación óptima, pésima y pesimista, La estimación puede basarse en datos históricos (tomar métricas sobre el proyecto), experiencia / intuición, Una variación razonable en las estimaciones es una franja del 20%Riesgos:
todo aquello que pueda afectar negativamente al proyecto de software. Se clasifican
Ámbito (del proyecto, técnicos, de negocio),Predictibilidad (conocidos por el personal, desconocidos pero identificables, impredecibles). Tiposriesgo:de Proyecto (amenazan al plan de proyecto: presupuesto, planificación, personal, recursos, participantes, requisitos), de técnicos (amenazan calidad del software: diseño,implementación, interfaz, verificación, mantenimiento), de negocio (amenazan la viabilidad del proyecto: riesgo de mercado, de estrategia, de

Ventas, administrativo, presupuestario)


Estrategias:Reactiva:Supervisa el proyecto en previsión de posibles riesgos, se asignan recursos por silos riesgos se convierten en problemas, El equipo no se preocupa de los riesgos hasta que algo va mal, El equipo intenta sofocar el problema,Cuando se falla entra en acción la gestión de crisis.
Proactiva:Comienza antes que los trabajos técnicos, se identifican riesgos potenciales, seevalúa la probabilidad y consecuencias de los riegos, se priorizan los riesgos, se produce un plan de gestión del riego, el objetivo es evitar el

Riego aunque también se proporcionan planes de contingencia


Pasos:Valoración del riesgo:identificación, análisis y priorización de riesgos


Control de riesgo:Planificación, resolución y monitorización del riesgo. Identificación:produce listas de elementos de riesgo específicos para el proyecto que comprometan seriamente su éxito, técnicas -> Listas de comprobación de elementos de riesgo (tabla de los Top 10 Software RiskÍTEMS de Boehm, Taxonomía SEI de Riesgos del Software), Análisis de supuestos.Planificación:convierte la información sobre riesgos en decisiones y acciones para el presente y el futuro (Desarrollar acciones para controlar riesgos individuales, Priorizar las acciones contra los

Riesgos, Crear un Plan de Gestión del Riesgo)


Métricas:Métricas de proyecto:Se emplean para determinar el curso del proyecto actual (Se emplean datos históricos para hacerla, A medidaque avanza el proyecto, las medidas del esfuerzo y el tiempo se comparan con las de la planificación) también se emplean métricas técnicas o deproducto para medir las técnicas de diseño y programación.
Métricas del software(El contexto de uso identifica al tipo de métrica), Métricas de productividad:(Orientadas al tamaño => medidas por LDC, función => medidas por PF, otras medidas por esfuerzo => PM) lDC
Ventajas:Fácilde calcular, existen muchos modelos, existen muchas medidas, Inconvenientes:Dependientes de los lenguajes de programación, perjudican a los programas cortos pero bien diseñados, difícil uso en estimación debido al nivel de detalle que requieren. PF puntos de función:Se basan:entradas y salidas al usuario, consultas del usuario, archivos usados por el sistema, interfaces externos.
Ventajas:Independientes del lenguaje deprogramación, Permiten hacer estimaciones más fácilmente. Inconvenientes:Basadas en cálculos subjetivos, Parámetros y factores no evidentes, No tienen un significado físico directo. PC puntos de carácterística:es una ampliación de PF, prima la dimensión de los datos,obviando cuestiones de complejidad funcional, inadecuada para sistemas de ingeniería empotrados. Métricas de calidad:la base de la IS es la calidad, que se mide en base a métricas: técnicas del producto (calidad de análisis, diseño, codificación), de calidad (Relacionadas entre otrosaspectos con errores, defectos, tiempo de cambio, integridad).
Calidad del software:Podemos definir calidad en base a carácterísticas o atributos de elementos del producto o proceso.
Tipos:calidad de diseño (Se basa en las carácterísticas especificadas para un elemento), calidad de concordancia (Se centra en el grado de cumplimento de las especificaciones de diseño durante su realización),
Como conseguir calidad:Haciendo SRS, diseños e implementaciones técnicas, Introduciendoen el modelo de proceso una serie de actividades que garanticen que todas las entregas sean correctas.
Garantía de Calidad del Software:técnicas de IS para conseguir calidad en el software. Control de calidades una serie de inspecciones, revisiones y pruebas utilizados a lo largodel proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados.
Coste de calidad:incluye todoslos costes que se derivan de la búsqueda de la calidad o en las actividades relacionadas con la obtención de la calidad, hay tres tipos: de prevención (planificación de calidad, RTFs, equipo de pruebas, formación), de evaluación (Calibrado y mantenimiento del equipo, pruebas), de fallos (internos => revisión, reparación, análisis de fallos; externos => resolución de quejas, devolución y sustitución de productos, soporte enlínea).
Verificación y validación:procesos que determinan si los productos desarrollados de una actividad dada se ajustan a los requisitos de esa

Actividad, y si el software satisface su uso deseado y las necesidades del usuario


Términos de Boehm:La verificación se encarga de comprobarsi estamos construyendo el producto correctamente, La validación se encarga de comprobar si estamos construyendo el producto correcto.
Niveles de integridad:carácterísticas del proyecto que determinan el grado de rigor a la hora de aplicar las actividades de V&V. (consecuencias graves, serias, menores, insignificantes),

Revisiones técnicas formales RTFs:(detectar errores antes de quese conviertan en defectos.)


Objetivos:descubrir errores, verificar que el sw alcanza sus requisitos, garantizar que el sw se desarrolla en base a unos estándares, hacer que los proyectos sean mas manejables.
SRS:Con la especificación de requisitos es posible realizar una planificación y estimación de costes que reduce el esfuerzo de desarrolloEn este documento identificamos la funcionalidad de nuestra aplicación, las interfaces externas, prestaciones, atributos y restricciones de diseño

Impuestas a la implementación


Restricciones proyecto:lenguaje Java por ser multiplataforma, aplicación tiene que poder usarse paralelamente por más de un usuario,la aplicación no puede permitir el acceso a ella a usuarios que no tengan una cuenta, interfaz gráfica de usuario debe ser intuitiva y fácil,la aplicación debe ser fiable, estable y robusta.Atributos del sistema software: fíabilidad: al no depender de otros sistemas completamente, se reduce el riesgo de fallos, mantenibilidad:cada cierto tiempo se harán revisiones técnicas formales para asegurar el buen funcionamiento del sistema,
portabilidad: la aplicación tienecompatibilidad con tres sistemas operativos, luego se puede portar a otro computador. En el plano hardware, la aplicación no tendrá portabilidad
a dispositivos móviles o tablets, aunque en un futuro podría ser portado, seguridad: el sistema está restringido a los usuarios de la tienda, ya querequiere un login con password. El password estará encriptado.