INFORME PRACTICAS

PRACTICA  LIMPIEZA Y ENSAMBLE DEL EQUIPO

Material Utilizado:
-Brocha pequeña
-Desarmador punta plana
-Desarmador punta de cruz

Para esta practica el maestro nos dividio en equipos a los cuales les fue asignado una pc a cada uno, despues cada equipo tenia que desarmar su pc iniciando por desconectar equipo de la fuente de luz, desconectar los  perifericos como el mouse, teclado, monitor, etc; quitar los tornillos del gabinete e ir quitando cada componente de la pc (memoria ram, memoria de video, disco duro, fuente de poder, targeta madre, etc) para limpiarlos posteriormente con la brocha y finalizando volviendo a colocarlos en el orden correcto y verificando que la pc funcionara correctamente.

En lo personal esta practica me sirvio porque aprendi mas sobre el mantenimiento que se debe dar a una pc,  me ayudo a conocer mejor los componentes de la misma y aprendi como ensamblarla correctamente.


PRACTICA  INSTALACION DEL SISTEMA OPERATIVO (WINDOWS 7)

Material utilizado:
-DVD de instalacion SO Windows 7

Esta practica consistio en formatear e instalar nuevamente el sistema operativo a una pc, para esto el maestro nos grabo a todos en un DVD el SO Windows 7 para instalarlo posteriormente.
Para instalar el sistema operativo lo primero que hicimos fue insertar el DVD en la unidad para que el equipo lo leyera al iniciar, para eso tuvimos que configurar el BIOS, despues inicio la instalacion y en el proceso tuvimos que eliminar las particiones existentes para crear nuevas y darles formato, tambien teniamos que darle un nombre al equipo, elegir la zona horaria y colocarle una contraseña si queriamos, al finalizar la instalacion se reiniciaba la pc y teniamos que retirar el DVD de instalacion para que iniciara correctamente, posteriormente se le instalo la paqueteria de software que nos indico el maestro y haci finalizo la practica.

Pues esta practica no me sirvio de mucho porque ya conocia algo acerca de la instalacion de sistemas operativos pero igualmente me sirvio de practica. 

TRABAJO CORREGIDO

PARA LOS DEL EQUIPO DE ECOLOGIA SI QUIEREN VER EL TRABAJO DEJENME SU DIRECCION DE CORREO EN UN COMENTARIO PARA ENVIARSELO PQ NO LO PUEDO POSTEAR EN EL BLOG TAL Y COMO ESTA, COMENTEN Y COMO A LAS 5 PM SE LOS ENVIO.

POR CIERTO ¿QUIEN LO VA A IMPRIMIR? TAMBIEN LO COMENTAN.

TAREA VISUAL BASIC

INGENIERÍA DEL SOFTWARE

Ingeniería de software es la disciplina o área de la Ingeniería que ofrece métodos y técnicas para desarrollar y mantener software.

METODOLOGÍA

Etapas del proceso:

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Análisis de requerimientos

Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI (Capability Maturity Model Integration o Integración de Modelos de Madurez de Capacidades). Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

Especificación

La Especificación de Requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

·         Casos de Uso: Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software.

·         Historias de usuario: Es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario.

Siendo los primeros más rigurosos y formales, los segundas más ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:

·         Diagramas de clases

·         Diagramas de base de datos

·         Diagramas de despliegue plegados

·         Diagramas de secuencia multidireccional

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar. Entre las herramientas para diseñar arquitecturas de software se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones UML (Unified Modeling Language o  Lenguaje Unificado de Modelado), casos de uso diagramas, pruebas, manuales de usuario, manuales técnicos, etc.; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.

Modelos de desarrollo de software

La ingeniería de software tiene varios modelos, paradigmas o filosofías de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

·         Modelo en cascada o Clásico (modelo tradicional)

·         Modelo de prototipos

·         Modelo en espiral

·         Desarrollo por etapas

·         Desarrollo iterativo y creciente o Iterativo e Incremental

·         RAD (Rapid Application Development)

·         Desarrollo concurrente

·         Proceso Unificado

·         RUP (Proceso Unificado de Rational)

Naturaleza de la IS:

La Ingeniería de Software tiene que ver con varios campos en diferentes formas:

Matemáticas

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.

Creación

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que encontramos en la IS.

Gestión de Proyectos

El software comercial (y mucho no comercial) requiere gestión de proyectos. Hay presupuestos y establecimiento de tiempos. Gente para liderar. Recursos (espacio de oficina, computadoras) por adquirir. Todo esto encaja apropiadamente con la visión de la Gestión de Proyectos.

Arte

Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald Knuth es famoso porque ha argumentado que la programación es un arte.

MANUALES

MANUAL DE USUARIO

El manual de usuario es un documento técnico de un determinado sistema que intenta dar asistencia que sus usuarios.

Los manuales de usuario generalmente son incluidos a dispositivos electrónicos, hardware de computadora y aplicaciones. El manual de usuario puede venir tanto en forma de libro como en forma de documento digital, e incluso poder ser consultado por internet.

En general, un manual de usuario debería poder ser entendido por cualquier usuario principiante, como así también serle útil a usuarios avanzados.

UN MANUAL DE USUARIO COMPLETO SUELE TENER:

* Un prefacio, con información sobre cómo usar el propio manual.
* Un índice.

* Análisis y requerimientos del sistema.
* Una guía rápida sobre cómo usar las funciones principales del sistema.
* Una sección para la resolución de problemas.
* Una FAQ.
* Información de contacto.
* Un glosario.

AL ESCRIBIRLO SE DEBE TOMAR EN CUENTA LOS SIGUIENTES PUNTOS:

• Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor dificultad posible.

• Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el programa.

• Especificar los alcances y las limitaciones que tiene el programa.

• Un buen punto de partida para un manual de usuario, es hacer de cuenta que las personas que lo van a leer no tienen el más mínimo conocimiento sobre computadoras.

MANUAL TÉCNICO

Un manual técnico es aquel que va dirigido a un público con conocimientos técnicos sobre algún área.

Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional. 

EL MANUAL TÉCNICO, DEBE INCLUIR:

-Identificación del documento:

 1. Logotipo de la organización.

2. Nombre oficial de la organización.

3. Denominación y extensión.

4. Lugar y fecha de elaboración.

5. Número de revisión.

6. Unidades responsables de su elaboración, revisión y/o autorización.

7. Clave de la forma.

-Estructura del documento:

1. Índice

2. Introducción.

2.1. Objetivo general del sistema

2.2. Objetivos específicos

3. Contenido técnico

3.1. Definición de reglas del negocio implementadas en el sistema desarrollado.

3.2. Diagramas de flujo de datos, junto con su respectivo diccionario de datos.

3.3. Controles de auditoría implementados en el sistema.

3.4. Descripción de campos requeridos por pantalla con presentación de pantallas.

3.5. Diagrama de navegación del sistema.

3.6. Requerimientos de interface con otros sistemas.

3.7. Modelo lógico de datos, diagrama entidad-relación.

3.8. Modelo de datos físico, junto con su respectivo diccionario de datos.

3.9. Matriz de procesos versus organización.

3.10. Matriz de programas versus entidades.

3.11. Plataforma de usuario.

3.12. Áreas de aplicación y/o alcance de los procedimientos.

4. Responsables.

4.1. Mapa de navegación

4.2. Descripción gráfica del mapa de navegación.