domingo, 28 de mayo de 2017

Modelo constructivo de costos

El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics"  (Prentice-Hall, 1981). COCOMO es una jerarquía de modelos de estimación de costes software que incluye submodelos básico, intermedio y desarrollado.
Las ecuaciones de estimación del esfuerzo de desarrollo tienen la forma:
Con:
• S el número de miles de líneas de código fuente
• m(X) es un multiplicador que depende de 15 atributos
• en la siguiente tabla se muestran los coeficientes para los diferentes modos

Modelo Básico
Este modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría de proyectos pequeños y medianos. Se consideran tres modos de desarrollo en este modelo: orgánico, semiencajado y empotrado.

Modo orgánico.
En este modo, un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio), mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes. En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga.
Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo. El coste es: Km = 2.4 Sk1.05  ; donde Km se expresa en personas-mes y Sk es el tamaño expresado en miles de líneas de código fuente. El tiempo de desarrollo se da por: td = 2.5 Km0.38  ; donde Km se obtiene de la ecuación anterior y td es el tiempo de desarrollo en meses. Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm en TRW sobre 63 proyectos.

Modo Empotrado.
En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y el interface hardware. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes. Así el coste se da por: Km = 3.6 Sk1.20 y el tiempo de desarrollo por td = 2.5 Km0.32 .

Modo Semiencajado.
Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas. Las ecuaciones son: Km = 3.0 Sk1.12 y el tiempo de desarrollo por td = 2.5 Km0.35.

Modelo Intermedio
En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisión de la estimación.

Atributos de coste.
Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo. De un análisis estadístico de más de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO. Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto.

Modelo Detallado
Este modelo puede procesar todas las características del proyecto para construir una estimación. Introduce dos características principales:
(1)   Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase del proyecto.
(2)   Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al que es más susceptible la variación.

Conclusion
Es uno de los modelos más documentados en la actualidad y es muy fácil de utilizar. Es correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe desprender que deba ser válido siempre. Una preocupación es la adaptación de las ecuaciones exponenciales a organizaciones específicas, cosa que no parece inmediatamente fácil.


domingo, 14 de mayo de 2017

Big Data

Introducción
Se pueden tratar conceptos que guardan una estrecha relación con el Big Data, como Business Intelligence, minería de datos u open data. Asimismo, frente a las denominadas”3V” que constituyen la esencia del Big Data  (volumen, variabilidad, velocidad), se sugiere una Big Data cuarta V, la de la visualización. Finalmente, tras anticipar la previsible problemática en torno a la gestión de la privacidad de la información, concluye con una reflexión acerca de la dimensión del concepto  en Big un contexto de crecimiento exponencial de la información y la seguridad que debe proporcionar la misma.

Desarrollo
Big Data apareció en el año 2015 como uno de los términos de moda en todas las revistas de temática científica, sociológica o tecnológica, también en  y redes sociales e incluso ya ha dado el salto a las blogs publicaciones económicas y empresariales y las de divulgación más popular.

Tradicionalmente, los principales conceptos agrupados que han definido este nombre han sido las denominadas ‘3 V’: volumen, variabilidad y velocidad. Macro datos es todo aquello que tiene que ver con grandes Volúmenes de información que se mueven o analizan a alta Velocidad y que pueden presentar una compleja Variabilidad en cuanto a la estructura de su composición. Siempre me ha parecido que debería añadirse una cuarta uve, la Visualización, ya que no solo forma también parte de ello, sino que muchas de las imágenes que nos traen a la memoria el trabajo con  tienen que ver con estas Big Data nuevas formas de ‘ver’ estos datos.


También al  Big Data se lo puede definir como aquel conjunto de datos que excede la capacidad de procesamiento de los sistemas de bases de datos convencionales.

Ventajas y desventajas
Es importante comprender que además de los datos estructurados, aquellos otros que provienen de fuentes de información conocidas y que, por tanto, son fáciles de medir y analizar a través de los sistemas tradicionales, empezamos a poder y querer manejar datos no estructurados: los que llegan de la Web, de las cámaras de los móviles y vídeos, redes sociales, sensores de las ciudades y edificios.

Por ende aquí se pueden mencionar a los atributos principales para considerar un conjunto de datos como Big Data:

Volumen: Cantidad masiva del orden de los cientos de Terabytes.
Velocidad: El flujo de entrada de datos, ingesta, puede resultar tan alto que la información sea muy difícil de procesar y esto condicione la comprensión sobre los datos.
Variedad: En la estructura de los datos: estructurados, semiestructurados (ficheros con formato conocido tipo Word, Excel) y desestructurados (imágenes, video, audio).
Valor: La mayoría de los datos tiene poco valor hasta su análisis y procesamiento. Para esta tarea se hacen necesarios sistemas distribuidos y recursos avanzados de análisis de datos.

Herramientas

Existe ya una gama amplia de utilidades (principalmente en la ayuda de toma de decisiones en situaciones críticas) es una de las herramientas fundamentales para la creación de valor sobre Big Data. En este sentido, además de las herramientas de procesamiento, son totalmente necesarios sistemas de visualización avanzada e interfaces que permitan interactuar con la propia visualización. La llegada de HTML-5 ha impulsado la aparición de un gran número de herramientas de visualización web adecuadas para la visualización científica y Visual Analytics.
El problema que posee Big Data es el de la privacidad que es en donde se deben enfatizar así como también en la seguridad, en la propiedad intelectual, e incluso con la responsabilidad, estos son los aspectos que deben ser abordados para que se pueda continuar con el desarrollo de los sistemas de Big Data.

Conclusión
Big Data es un concepto con un gran potencial que ya empieza a tener una importante difusión pero aún el potencial del concepto no ha sido todavía explorado en su totalidad. Son muchos los nuevos campos y oportunidades que se abren en torno a este mundo. Es en la capacidad de analizar la gran cantidad de información que nos ofrece el Big Data donde las herramientas avanzadas de visualización son y serán un factor clave en el éxito del desarrollo de estas tecnologías.

domingo, 7 de mayo de 2017

Analisis de Diseño

Introducción
 Antes de comenzar con el proyecto de creación, diseño y estructura de nuestra página web, debemos haber planificado ya previamente las estrategias a llevar a cabo si queremos tener éxito en nuestro proyecto de posicionamiento natural web en internet.
Antes de nada tenemos que analizar todos los aspectos que hacen referencia a nuestra nueva página web, desde el diseño de la página web, análisis de la estructura interna de la página web, análisis de los textos web, análisis de las keywords de la web, análisis y estudio de nuestra competencia en internet, del sector o empresa al que pertenece, análisis del tipo de cliente idealal que ofrecemos nuestros productos, nuestros servicios.
Una vez hayamos analizado todos estos aspectos tanto los internos como los aspectos externos de nuestra página web, nos pondremos a analizar globalmente todos los datos recabados, haciendo si fuera el caso, una completa auditoría del negocio web al que deseamos un posicionamiento natural, para, posteriormente llevar a cabo todas las estrategias de marketing estudiadas previamente para que todos nuestros productos a la venta o servicios que ofrezcamos a los posibles clientes o visitantes a nuestra página web.

Analisis, Diseño y estructura de paginas WEB
En un proyecto de creación de páginas web de nueva, el estudio del diseño, geometría, colores corporativos, código a usar en el sitio web se realiza a cargo de nuestros diseñadores y creativos que, en conjunción con nuestros técnicos de marketing, realizarán el diseño global de la página web, estudiando la estructura tanto a nivel de diseño como en la programación del código html del sitio, la estructura lógica de la página y depuración del mismo.

SEARS
-Diseño de interfaz
Su interfaz es bastante llamativa, porque su inicio muestra un producto de cada sección que manejan como celulares, TV o electrodomésticos,  que son los últimos que han salido, con lo cual es llamativo para alguien que entra buscando lo que cubra sus necesidades. Todos los botones son claros y es bastante limpia con un fondo blanco y frases bastante llamativas eh inspiradoras.

-Mapa de navegación
Su mapa de navegación es sencillo, consta de cuatro secciones principales que es los tipos de productos que manejan, al meterte a alguno se muestran todos los artículos disponibles de esa sección con imágenes y comparaciones.

-Contenidos
Su contenido se basa en la demostración de todos los artículos que la marca maneja, explicando todas las especificaciones de cada uno con imágenes para mostrarlo de diferentes ángulos y con sus respectivos costos.

SPOTIFY
-Diseño de Interfaz
El css de la página esta bueno, con sus respectivas animaciones y no es molesto para los ojos, son simples pero no exageradas.

-Mapa de Navegación
El mapa de navegación es de un solo nivel y consta de 3 ramas, asi que el usuario no se satura de información o se pierde buscando algo.

-Contenidos
La página está completa, ya que tiene el contenido necesario para que descargues el software y hasta te persuada de comprarlo. En la página principal viene todo lo que se necesita.

lunes, 1 de mayo de 2017

Calidad del Software

La calidad del software requiere de mucho esfuerzo y preocupación, las personas encargadas de llevar a cabo el trabajo anterior deberán ser aquellas que conozcan profundamente cada una de las partes del proyecto tanto teóricas como prácticas. La calidad debe aplicarse a todos los niveles de la organización, sin embargo es necesario que sea adoptada una estructura organizacional, la cual ayudará a evitar el desperdicio de esfuerzo y de recursos; el software puede tener errores, incidencias; ya que casi nunca es perfecto. La calidad del software no se puede medir de forma correcta debido a su naturaleza, la calidad del software depende de quien la juzgue o del correcto funcionamiento del mismo garantiza un buen software.
Los puntos que se tocaran son los siguientes:
•  Facilidad de Uso: Conjunto de características que influyen en el esfuerzo requerido para el uso y la evaluación individual de cada uso por parte de un conjunto de usuarios dados. Se divide en las subcaracteríticas comprensión, facilidad de aprendizaje, operatividad, atractivo.
•  Funcionalidad: Funcionalidad es lo que un producto puede hacer. Probar la funcionalidad significa asegurar que el producto funciona tal como estaba especificado.
•  Confiabilidad: La habilidad que tiene un sistema o componente de realizar sus funciones requeridas bajo condiciones específicas en periodos de tiempo determinados
•  Eficiencia: Se define como la capacidad de disponer de alguien o de algo para conseguir un efecto especifico. No debe confundirse con eficacia que se define como la capacidad de lograr el efecto que se desea o se espera.
•  Facilidad de mantenimiento: Respecto a la calidad de un programa, la facilidad de mantenimiento hace referencia a establecer en qué medida el programa es susceptible de ser corregido.
Conclusión
Siempre es importante tener en cuenta la calidad de nuestra aplicación para satisfacción del cliente y con los puntos vistos en este trabajo, ya será fácil identificar que tan completa es nuestra aplicación.
Referencias


domingo, 9 de abril de 2017

Investigacion Ingenieria de Software

Recopilación de Requerimientos
Se divide en 7 conceptos:
-Concepción. ¿Cómo inicia un proyecto de software? ¿Existe un solo evento que se convierte en el catalizador de un nuevo sistema o producto basado en computadora o la necesidad evoluciona en el tiempo? No hay respuestas definitivas a estas preguntas. En ciertos casos, una conversación casual es todo lo que se necesita para desencadenar un trabajo grande de ingeniería de software. Pero en general, la mayor parte de proyectos comienzan cuando se identifica una necesidad del negocio o se descubre un nuevo mercado o servicio potencial.
-Indagación. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras personas cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el sistema o producto en las operaciones cotidianas. Pero no es simple: es muy difícil.
Se han identificado cierto número de problemas que se encuentran cuando
Ocurre la indagación:
• Problemas de alcance.
• Problemas de entendimiento.
• Problemas de volatilidad.
-Elaboración. La elaboración está motivada por la creación y mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del dominio del negocio visibles para el usuario final.
-Negociación. No es raro que los clientes y usuarios pidan más de lo que puede lograrse dado lo limitado de los recursos del negocio. También es relativamente común que distintos clientes o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esencial para nuestras necesidades especiales”. 
-Especificación. En el contexto de los sistemas basados en computadora (y software), el término especificación tiene diferentes significados para distintas personas. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.
-Validación. La calidad de los productos del trabajo que se generan como consecuencia de la ingeniería de los requerimientos se evalúa durante el paso de validación. La validación de los requerimientos analiza la especificación a fin de garantizar que todos ellos han sido enunciados sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.
-Administración de los requerimientos. Los requerimientos para sistemas basados en computadora cambian, y el deseo de modificarlos persiste durante toda la vida del sistema. La administración de los requerimientos es el conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.

Preguntas de Formulación
Antes de preocuparse por las preguntas de formulación que debe hacer, debe identificar quién será el objetivo de las preguntas. Necesitará identificar a las partes interesadas. Una parte interesada puede definirse como "cualquier persona que se beneficia directa o indirectamente del sistema que se está desarrollando" -Ian Sommerville.
En el mejor de todos los mundos, una persona será el centro de sus preguntas. Este individuo tendrá una experiencia empresarial adecuada, un buen conocimiento técnico y la autoridad para negociar las necesidades en términos de tiempo de entrega y recursos. Sin embargo, es más probable que se ocupe de un número de diferentes partes interesadas, cada una con un punto de vista diferente, a veces necesidades divergentes y conocimientos técnicos y de negocios sustancialmente diferentes. En general, las partes interesadas se basan en las siguientes categorías: gerentes de negocios, gerentes de producto, personas de marketing, clientes internos y externos, usuarios finales, consultores, ingenieros de productos, ingenieros de Web y personal de soporte y mantenimiento.

Definición de las Categorías de Usuario
-Gerentes y altos ejecutivos. Son los que se les permite controlar, controlar y, en general, gestionar los procesos institucionales. Son sistemas de apoyo a las personas y equipos que tienen que estar pendientes si las "cosas funcionan bien". Algunas características clásicas de estos tipos de usuarios requieren que organicen y resuelvan las decisiones semiestructuradas, realicen la gestión de riesgos bajo diversos escenarios y lleven a cabo la planificación con un horizonte a la escala de meses, trimestre o año.
-Operadores. Ellos son responsables de acceder a la información crítica de negocios y tener la capacidad de distribuir dicha información a las diferentes personas de la organización y los usuarios para asegurar la toma de decisiones basadas en información precisa, confiable y oportuna que puede afectar el desarrollo y el éxito del negocio.

Desarrollo de Casos de Uso
En ésta es posible identificar a los actores principales, y a los secundarios cuando se sabe más del sistema. Los actores principales interactúan para lograr la función requerida del sistema y obtienen el beneficio previsto de éste. Trabajan con el software en forma directa y con frecuencia. Los actores secundarios dan apoyo al sistema, de modo que los primarios puedan hacer su trabajo.
Una vez identificados los actores, es posible desarrollar casos de uso. Se sugieren varias preguntas que debe responder un caso de uso:
• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
• ¿Cuáles son los objetivos de los actores?
• ¿Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿Qué excepciones deben considerarse al describir la historia?
• ¿Cuáles variaciones son posibles en la interacción del actor?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
• ¿Qué información desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?

miércoles, 5 de abril de 2017

Mejores Practicas de la Ingeniería Web

Nosotros sabemos que los equipos de ingeniería web a veces están bajo una enorme presión de tiempo y tratará de tomar atajos. También aceptamos el hecho de que algunos equipos de WebE quieren mantener las cosas muy informales y rechazar la noción de un marco de proceso y definir métodos como una cuestión de filosofía. Se cree que ese tipo de razonamiento es erróneo, pero es una llamada hecha, esperando que se pase suficiente tiempo evaluando cada una de las prácticas que se describen a continuación, aceptando aquellas que parezcan aplicables y rechazar a los que no lo hacen. Como un mínimo absoluto, también se espera que se adopten las siguientes prácticas recomendadas cuando desarrollen WebApps de cualquier índole:

1.    Debe tomarse el tiempo para entender las necesidades del negocio y los objetivos del producto. Muchos WebApp erróneamente creen que los requisitos comunes les libera de la necesidad de asegurarse de que el sistema acerca de ingeniero tiene un propósito comercial legítimo. El resultado final es el buen trabajo técnico que da lugar al sistema incorrecto que es construido por las razones equivocadas y por el público equivocado. Si las partes interesadas no pueden enunciarse como una necesidad de negocio para el WebApp, debe procederse con extrema precaución. Si las partes interesadas luchan por identificar un conjunto de objetivos claros para el producto (WebApp), no debe procederse hasta que puedan.

2.    Describir cómo los usuarios interactuarán con el WebApp utilizando un enfoque. Se debe convencer a las partes interesadas de que desarrollen escenarios que reflejan cómo los distintos usuarios interactuarán con la Aplicación Web. Estos escenarios pueden ser utilizados: para la planificación de proyectos y para orientar el análisis y modelado del diseño, y más importante, para el diseño de pruebas.

3.    Debe desarrollarse un plan de proyecto, aunque sea muy breve. Base el plan en un marco de proceso que sea aceptable para todas las partes interesadas. Debido a que las líneas de tiempo del proyecto son muy cortas, utilice una granularidad "buena" para su programarla; es decir, en muchos casos, el proyecto debe programarse y rastreado sobre una base diaria.

4.    Pase algún tiempo modelando lo que es lo que vas a construir. Generalmente, no se desarrolla una documentación exhaustiva de análisis y diseño. Como parte del trabajo de ingeniería web. Sin embargo, los gráficos bien orientados modelos pueden iluminar ingeniería importante cuestiones.

5.    Revise los modelos de consistencia y calidad. Pasos a través de parejas y otros tipos de revisiones deben realizarse en un WebE proyecto. El tiempo dedicado a los exámenes paga dividendos importantes porque elimina la reelaboración y da como resultado una WebApp de alta calidad, lo que le da satisfacción al cliente.

6.    Utilice herramientas y tecnología que le permitan construir el sistema con tantos componentes reutilizables como sea posible. Una amplia gama de las herramientas de WebApp están disponibles para casi todos los aspectos de la construcción de WebApp. Muchas de estas herramientas permiten a un ingeniero de red construir significa -De la aplicación utilizando componentes reutilizables.

7.    No se debe reinventar cuando se puede reutilizar. Una amplia gama de patrones de diseño han sido desarrollados para WebApps. Estos patrones permiten a un equipo WebE Desarrollar detalles de arquitectura, navegación y componentes a Plantillas probadas.

8.    No confíe en los primeros usuarios para depurar el diseño WebApp las pruebas y ejecutarlas antes de liberar el sistema. Usuarios de un WebApp a menudo le dará una oportunidad. Si no funciona, se mueven en otro lugar, no se debe volver. Es por esta razón que "primero pruebe, después despliegue". Ésta, debe ser una filosofía primordial, incluso si los plazos deben ser estirados.


Referencias:

Roger S. Pressman , “Web Engineering: A Practioner's Approach”. 

domingo, 2 de abril de 2017

Atributos de las WebApps

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (haciendo posible así una comunicación abierta par todoel mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una Extranet (comunicación entre redes).

Controlada por el contenido. En muchos casos, la función primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo.
Evolución continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas WebApps (específicamente, su contenido) se actualicen cada hora. Un cuidado y una alimentación continua permite que un sitio Web crezca (en robustez y en importancia). Pero a diferencia de un jardín, las aplicaciones Web deben de servir (y adaptarse a) las necesidades de más de un jardinero, Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, implementación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

Seguridad. Dado que las WebApps están disponibles a través de1 acceso por red, es difícil, si no imposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisión de datos, deberán implementarse fuertes  medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuando se ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estética puede tener mucho que ver con el éxito del diseño técnico.

Categorias de los WebApps

Categoría
Descripción
Informativa
El contenido de solo lectura con navegación.
Descarga
Descarga información del servidor apropiado.
Personalizable
El usuario personaliza sus necesidades especificas.
Interacción
La interacción entre una comunidad de personas lo que se le conoce como relaciones sociales a través de Internet
Entrada de usuario
La entrada un registro para una base de datos un mecanismo para la comunicación.
Orientación a transacciones
El usuario realiza una solicitud por ejemplo hace un pedido aquí podemos poner muchos ejemplos como la compra de ebay o el encardo de supermercado pero también las transacciones de base de datos.


Proceso de Scrum


Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Hablando del proceso, un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.

Planeacion de iteracion

Primera parte de la reunión:
-Se realiza en un timebox de cómo máximo 4 horas.
-El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.
-El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

Segunda parte de la reunión.
-Se realiza en un timebox de cómo máximo 4 horas.
-El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cómo realizarlo.
-Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de completado.
-Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
-Cada miembro del equipo se autoasigna a las tareas que puede realizar.

Ejecucion de la iteracion

Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este disponible para ser utilizado. Para ello, durante la iteración el equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:

-Cada día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).
-El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.
    *Elimina los obstáculos que el equipo no puede resolver por sí mismo.
    *Protege al equipo de interrupciones externas que puedan afectar su compromiso o su       productividad.

El último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:
1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.

Referencias
https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)
http://juan-garcia-carmona.blogspot.mx/2012/08/mi-resumen-de-scrum.html

domingo, 19 de marzo de 2017

Historias de usuario

Historia de Usuario
Número: 10.                           
Nombre: Venta de tarjetas de metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro y cajero
Iteración Asignada: 1
Prioridad  en Negocio: Alta
Puntos Estimados: 10 horas
Riesgo en Desarrollo: Medio
Puntos Reales:
Descripción: El usuario del metro irá a un cajero a comprar una tarjeta que posteriormente usará para poder usar el servicio de metro e ir de una zona a otra o permanecer en la misma.

Observaciones:














Caso de Prueba de Aceptación
Código:

Historia de Usuario (Nro. y Nombre):
Venta de tarjeta No. 10
Nombre: Validación de tarjeta
Descripción: Al comprar la tarjeta que se valide su saldo y su id
Condiciones de Ejecución:
El usuario debe haber pagado la tarjeta
Entrada / Pasos de ejecución:
El usuario paga la tarjeta y la carga de saldo.
Resultado Esperado:
El sistema da de alta su id y acumula la cantidad de dinero que deposito el usuario.
Evaluación de la Prueba:














Tarea de Ingeniería
Número Tarea:
2
Historia de Usuario (Nro. y Nombre):
Venta de Tarjetas No. 10
Nombre Tarea: Tarifas de metro
Tipo de Tarea :
Desarrollo
Puntos Estimados:
10 horas
Fecha de Inicio:
09/03/2017
Fecha de culminación.
09/03/2017
Programador Responsable:
Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción:
Se hará un estándar de las tarifas para ir de una zona a otra especificando cuales son las estaciones que están en cada zona y así evitar confusiones. También se hará una tabla general en donde se coloquen todas las estaciones con sus posibles tarifas dependiendo de la zona  en que se encuentre y a las zonas en que puede acabar usando dicha estación.











Tarea de Ingeniería
Número Tarea:
1
Historia de Usuario (Nro. y Nombre):
Venta de Tarjeta No. 10
Nombre Tarea: Registro de Tarjeta
Tipo de Tarea :
Desarrollo
Puntos Estimados:
5 horas
Fecha de Inicio:
7/03/2017
Fecha de culminación.
7/03/2017

Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción:
Después de que el usuario haya comprado una tarjeta del metro se registrará la tarjeta y se validará para que pueda funcionar













Tarea de Ingeniería
Número Tarea:
3
Historia de Usuario (Nro. y Nombre):
Venta de Tarjeta No.10
Nombre Tarea: Recarga de Tarjeta
Tipo de Tarea :
Desarrollo
Puntos Estimados:
7
Fecha de Inicio:
08/03/2017
Fecha de culminación.
08/03/2017
Programador Responsable:
Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción:
Posteriormente de que el usuario del metro haya comprado la tarjeta de metro y el cajero después de que la haya activado y entregado al usuario, el usuario podrá recargar la tarjeta para que cuente con el crédito necesario para poder usar el servicio del metro (Se debe contar con el saldo necesario para ir de la zona 1 a la zona 3 y viceversa).











Historia de Usuario
Número: 20.                           
Nombre: Entrada del metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro
Iteración Asignada: 2
Prioridad  en Negocio: Alta
Puntos Estimados: 15 horas
Riesgo en Desarrollo: Baja
Puntos Reales:
Descripción: El usuario del metro tendrá acceso al servicio siempre y cuando tenga el saldo para cubrir la tarifa máxima.
Observaciones:















Caso de Prueba de Aceptación
Código:

Historia de Usuario (Nro. y Nombre):
Entrada del metro No.20
Nombre: Checar monto
Descripción: Si el monto en la tarjeta es el necesario para pasar al metro.
Condiciones de Ejecución:
El usuario previamente tuvo que haber comprado su tarjeta.
El sistema tuvo que haber dado de alta el id del usuario.
Entrada / Pasos de ejecución:
El usuario pasara la tarjeta por el lugar de cobranza con un monto por debajo de la tarifa estimada
Resultado Esperado:
El sistema le pedirá al usuario que recargue su tarjeta en taquilla y vuelva cuando la tarjeta contenga más o igual monto del que se pide.
Evaluación de la Prueba:












Caso de Prueba de Aceptación
Código:

Historia de Usuario (Nro. y Nombre):
Entrada del metro No.20
Nombre: Checar monto 2
Descripción: Si el monto en la tarjeta es el necesario para pasar al metro.
Condiciones de Ejecución:
El usuario previamente tuvo que haber comprado su tarjeta.
El sistema tuvo que haber dado de alta el id del usuario.
Entrada / Pasos de ejecución:
El usuario pasara la tarjeta por el lugar de cobranza con un monto por encima de la tarifa estimada
Resultado Esperado:
El sistema dejara entrar al usuario.
Evaluación de la Prueba:













Tarea de Ingeniería
Número Tarea:
1
Historia de Usuario (Nro. y Nombre):
Entrada del metro No. 20
Nombre Tarea: Entrada
Tipo de Tarea :
Desarrollo
Puntos Estimados:
15 horas
Fecha de Inicio:
09/03/2017
Fecha de culminación.
11/03/2017
Programador Responsable:
Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción:
Teniendo ya validada la tarjeta en la previa venta y recarga el sistema reconocerá la tarjeta correspondiente al asignarle un id valido y tomando el monto solicitado del acumulado en la tarjeta. En el caso de que no tenga la cantidad requerida se le pedirá que vuelva a recargar en taquilla.












Historia de Usuario
Número: 10.                           
Nombre: Entrada del metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro
Iteración Asignada: 2
Prioridad  en Negocio: Alta
Puntos Estimados: 15 horas
Riesgo en Desarrollo: Baja
Puntos Reales:
Descripción: El usuario del metro tendrá acceso al servicio siempre y cuando tenga el saldo para cubrir la tarifa máxima.
Observaciones:















Caso de Prueba de Aceptación
Código:
Sección o parte del código  a probar
Historia de Usuario (Nro. y Nombre):
Nombre de la historia de usuario a la cual se le aplicará el correspondiente caso de prueba
Nombre: Nombre que recibe el caso de prueba
Descripción: Se describe que es lo que el cliente pretende probar
Condiciones de Ejecución:
Se describe las condiciones bajo las cuales se debe probar el caso de prueba por ejemplo.
El usuario debe haber iniciado sesión
El sistema tiene que estar conectado a internet
Entrada / Pasos de ejecución:
Se describen los pasos necesarios para llevar a cabo el caso de prueba, o los diferentes datos que se quieren capturar para saber la respuesta que tendrá el sistema.
Resultado Esperado:
Se anotan los resultados esperados que se cree arrojará el sistema.
Evaluación de la Prueba:
Se hace una comparación de los resultados obtenidos con los esperados y se toman las decisiones pertinentes









Tarea de Ingeniería
Número Tarea:
1
Historia de Usuario (Nro. y Nombre):
Entrada del metro No. 10
Nombre Tarea: Entrada
Tipo de Tarea :
Desarrollo
Puntos Estimados:
15 horas
Fecha de Inicio:
09/03/2017
Fecha de culminación.
11/03/2017
Programador Responsable:
Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción:
Teniendo ya validada la tarjeta en la previa venta y recarga el sistema reconocerá la tarjeta correspondiente al asignarle un id valido y tomando el monto solicitado del acumulado en la tarjeta. En el caso de que no tenga la cantidad requerida se le pedirá que vuelva a recargar en taquilla.