DIAGRAMA DE CLASES
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
    • Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.
    • Operaciones son aquellas actividades o verbos que se pueden realizar para este objeto, por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.
    • Interfaz es un conjunto de operaciones y o que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto.
    • Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y o propiedades de un objeto padre. ejemplo: Una persona puede subdividirse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario...

bunas en esta secion le hablare un poco de el diseño del software.
En esta etapa del desarrollo se llevan a cabo algunos bosquejos, o diagramas que permiten comprender la magnitud del software y facilitan al desarrollador estructurar de su trabajo. Es común referirse a estos diagramas como los planos del software, haciendo analogía con la arquitectura.
La finalidad del diseño es tener una idea, al menos visual, y genérica de todo el sistema. Un buen análisis de requisitos, restricciomes, y otros factores que uno considere oportuno considerar puede llevar a un diseño bastante maduro y aproximado de como concebir al software.
Esto puede ser de mucha utilidad. Por ejemplo, nos sirve para determinar aquellos puntos sencibles o débiles. Esto puede indicarnos que allí hay que poner atención y analizar objetivamente. Por tanto, podríamos reestructurar todas las actividades teniendo en cuenta las necesidades y o el impacto del riesgo.

HERRAMIENTAS TIC

GLIFFY

YUML

CREATELY

son herramientas muy útiles para elaborar nuestros casos de usos al principio son  un poco complicadas pero cuando empiezas a utilizarla ya se nos hacen mas fáciles. 

REQUISITOS

estos son necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio.

estos son

Necesario: Lo que pida un requisito debe ser necesario para el producto.

Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aun así debe referenciar los aspectos importantes.

Consistente: No deben entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requisitos debe ser consistente.

Completo: Deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.

Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.

Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

REQUERIMIENTOS

Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 

Necesario: Es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

 

Conciso: Un requerimiento es conciso, si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. 

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. 

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. 

UML

en esta semana hablamos un poco de lo que es UML, un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema, este ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio o funciones del sistema.

DIAGRAMA DE CASO DE USO

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Donde los muñecos son los actores y los círculos las operaciones.

SEMANA DE PARCIALES
una semana muy larga para algunos y muy corta para otras, una semana en donde se puso apenas nuestros conocimientos, una semana que nos sirvió para afianzar nuestros conocimientos a reforzar nuestras dudas las cuales eran mucho pero que se logro salir adelante, esto fue muy provechoso, nos obliga a leer y estudiar un poco mas.

una semana muy productiva, no savia que era un cuatro de cuatro, una herramienta muy provechosa, hace que nos interesemos mas por las clases y que nos lleva a participar mas, muy interesante en un principio pensé que se nos iba a complicar pero con la introducción que nos hizo el profesor esta mas claro que antes.

hola muchachos blogeros  esta semana fue una semana muy provechosa aprendimos nuevas cosas que son y serán útiles para nosotros, aprendí lo que es un  ciclo de un software. aquí les dejo algo sobre los ciclos de vida espero comenten mi blogs.Ciclo de Vida del Softwareeste define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Alternativas de Modelos de Ciclo de Vida

Modelo Cascada

• sirve como bloque de construcción para los demás modelos de ciclo de vida. 
• Planear un proyecto antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Testear un sistema después de construirlo.

Modelo De Desarrollo Incremental

Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos.

• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
• Si un error importante es realizado, sólo la última iteración necesita ser descartada.
• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
• Si un error importante es realizado, el incremento previo puede ser usado.
• Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

El modelo de desarrollo evolutivo construye una serie de grandes versiones sucesivas de un producto.

• En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento.
• El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores.
• Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
• El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc.

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. 

• Determina qué quieres lograr.
• Determina las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
• Seguir la alternativa seleccionada en el paso 2.
• Establece qué tienes terminado. 

Modelo Concurrente

Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. 

buenas amigos blogeros esta semana fue una semana muy productiva, donde todos participaron; en esta semana aprendimos lo que son los riesgos informático, a la vulnerabilidad a las que nos encontramos expuestos y de la ocurrencia e impacto de la misma, a fin de determinar los controles adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo.

Análisis y Diseño Integral de Software

Su presencia en la vida diaria y empresarial es un hecho económico innegable. Las inversiones en software lo convierten en un bien estratégico indiscutible.

Un software cualquiera hoy en día debe integrarse a otros existentes, estos operarán que comparten varias funciones sobre varios proceso.

Existe gran cantidad de estudios en análisis y diseño de sistemas, siendo en general caracterizados por formar en temas aislados o sesgados o estancos entre las diversiones dimensiones de un análisis y un diseño.  Los resultados son sistemas con alto mantenimiento o expectativas de utilidad que son superadas por el uso diario.

En este sentido el Programa Análisis y Diseño Integral de Software, es un programa aborda el modelado integral de software en sus fases de análisis y diseño, teniendo siempre presente que el software no es un producto estático, sino un producto que evoluciona desde su concepción y afecta a las organizaciones transversalmente de una u otra manera.

Un software es un bien al mismo tiempo que genera oportunidades ata a una infraestructura y a un modelo de operación ‘algoritmizado’. Se aborda la tarea de modelamiento apuntando en sus diversas dimensiones y no pierde vista que al final de cuentas, un software es un recurso vivo que debe generar utilidades y/o ahorros.

Ésta semana que pasa una semana muy productiva, con una buena introducción a análisis y diseño de software, señalando todos los puntos de vista que se tendrán durante el semestre y las herramientas que necesitamos y actividades a realizar.
Que mas que las tic para aprender y aportar a la sociedad ya que por medio de este medio daremos a conocer todo lo aprendido durante las clases de cada semana y de todo el semestre.
para todos aquellos bloggeros que quieran dar su punto de vista de mi nuevo blogs aqui les dejo un vídeo de como crear un blogs con gmail una herramienta muy facil y muy productiva.

Aquí tienen un vídeo de los mapas mentales espero les sea útil.