domingo, 25 de septiembre de 2011
domingo, 18 de septiembre de 2011
sábado, 10 de septiembre de 2011
En lo personal a mi me gustó mucho realizar esta práctica porque pudimos conocer mas de cerca los componentes que permiten el funcionamiento de la computadora, así como reforzar el conocimiento de sus nombres y el lugar en el que van, así como limpiar porque ya tenían bastante polvo, para que puedan funcionar bien.
miércoles, 4 de mayo de 2011
Ingeniería de software
Ingeniería de software
La ingeniería de software se conoce también como Desarrollo de Software o Producción de Software y es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software. Es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos.
La Ingeniería del Software trata de sistematizar el proceso de la creación del software, con el fin de disminuir el riesgo del fracaso en la consecución del objetivo, por medio de diversas técnicas. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.
Metodología
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como:
Análisis de requerimientos
Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, en el cual 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. Hace la identificación de las necesidades del negocio, e 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. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.
§ Historias de usuario: Las historias de usuario son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requerimientos cambiantes.
Arquitectura
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.
Programación
Reducir un diseño a código. 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.
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: Lenguaje Unificado de Modelado), casos de uso diagramas, pruebas, manuales de usuario, manuales técnicos, etc; 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. 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.
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): es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.
§ Modelo de prototipos: el diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará.
§ Modelo en espiral: las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
§ Desarrollo por etapas: el modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.
§ Desarrollo iterativo y creciente o Iterativo e Incremental: es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworksg de desarrollo rápido de software.
§ RAD (desarrollo rápido de aplicaciones): es un proceso de desarrollo de software, El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades.
§ Desarrollo concurrente.
§ Proceso Unificado: es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
§ RUP (Proceso Unificado de Rational): es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Utilidad de un manual de usuario
El manual de usuario tiene como objetivo instruir al usuario en el uso del sistema y la solución de los problemas que puedan suceder en la operación.
Utilidad de un manual técnico
Cómo elaborar un manual de usuario
Pasos del manual del usuario:
1. Portada: De qué se trata el documento y quien lo elaboró
2. Introducción: Describe el uso del documento (para qué sirve) y de qué habla
3. Análisis y requerimientos del sistema (¿qué se ocupa para poder instalarlo y usarlo?)
3. Explicación del funcionamiento: Debes de poner paso a paso y con pantallas bien explicadas cómo funciona el programa
4. Glosario
• 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 computadores.
Cómo elaborar un manual técnico
Lleva 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.
Estructura del manual técnico
1. Índice
Relación de los capítulos y páginas correspondientes que forman parte del documento
2. Introducción.
Se debe presentar una breve descripción del sistema desarrollado, que contemple el ámbito abarcado, cual es su función principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.
2.1. Objetivo general del sistema
Se debe de describir el objetivo general del sistema.
2.2. Objetivos específicos
Se deben describir brevemente los objetivos específicos que se cumplieron con el desarrollo del sistema.
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. Aquí se describen los requerimientos mínimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).
3.12. Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren los procedimientos
4. Responsables.
Para iniciar los trabajos que conducen a la integración de un manual, es indispensable prever que no queda diluida la responsabilidad de la conducción de las acciones en diversas personas, sino que debe designarse a un coordinador, auxiliado por un equipo técnico, al que se le debe encomendar la conducción del proyecto en sus fases de diseño, implantación y actualización. De esta manera se logra homogeneidad en el contenido y presentación de la información. Por lo que respecta a las características del equipo técnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organización en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organización puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular del área específica. Asimismo, puede contratar los servicios de consultores externos.
4.1. Mapa de navegación. muestra de forma gráfica la interconexión entre cada una de las pantallas del sistema, lo que serviría para saber cómo llegar a determinada parte de la aplicación. En este se muestran los menús, submenús y pantallas a las que nos lleva cada uno de ellos
4.2. Descripción gráfica del mapa de navegación. En el anterior aparece de forma de diagrama de flujo y en esta sección deberá aparecer ya con las respectivas pantallas.
4.3. Describe paso a paso los procesos, así como pantallas, botones, cuadros de texto, etc., pero también se muestra el código de cada rutina, pantalla, botón, etc. es decir, se muestra lo que hay detrás de la interfaz del usuario
viernes, 11 de marzo de 2011
EXCEPTIONS ABOUT PROGRESSIVE
Before: Antes de
After: Después de
Without:sin
In spite of: A pesar de
Besides: Además
Instead of: En lugar de
1. On same time reading and listening music.
2. Before going to sleep, see the TV.
3. Without canning see the TV.
4. Besides of washing dishes tendinous beds.
5. In spite of read not understanding, the message.
6. Instead of buying the memory, buy the hard drive.
7. After of word opening page is set to start work.
Oral source: Inocencio Ventura Escamilla (retired teacher)
Know english since 22 years
Written source: http://www.ego4u.com/en/cram-up/grammar/present-progressive/exceptions
http://translate.google.com/translate?hl=es&langpair=enes&u=http://en.wikipedia.org/wiki/English_verbs
English notebook of the 4 th semester
Well I think it is good that we have investigated these 7 exceptions are handled in this progressive, because I think that helps us better understand and manage English in the most correct, both the writing and at some point to listen to or speak.
My name is Yesenia Pedraza Ventura
Specialty: Informatics 4º
sábado, 5 de marzo de 2011
Tarea
1.- Las variables, como su nombre lo indica, se utilizan para almacenar valores que tienen la propiedad de variar el contenido. Cuando hablamos de contenido nos referimos a cualquier tipo de datos, por ejemplo un nombre, una fecha, un color, un número etc. A las variables se les asigna un nombre para poder utilizarlas. Por ejemplo puedo crear una variable llamada fecha y esta almacenará una fecha. A los nombres de las variables se los denomina identificadores En visual basic a las variables conviene declararlas, o sea, avisarle a vb que vamos a utilizar dichas variables. A estas se las declara en el comienzo del código y se les antepone la palabra reservada Dim, luego el nombre que nosotros queramos y seguido el tipo de dato que almacenará, por ejemplo si quiero almacenar en una variable llamada Número, por ejemplo:
Dim numero As Integer
La palabra Integer le avisa a vsiaual basic que voy a guardar un número entero. Después de declararla le podemos asignar un valor con el operador "=", ejemplo:
Dim numero As Integer
numero = 1500
2.- Valor (alfanumérico / numérico) que nunca cambia durante el procesamiento de todas las instrucciones de un programa, pueden ser de cualquier tipo de datos.
Una vez que tiene un valor, éste NO cambia durante la ejecución del programa. La única manera de cambiar el valor de una constante, es cambiando el programa.
Las constantes, como las variables, se utilizan para guardar datos y valores para nuestro programa, pero a diferencia de estas últimas (las variables), el contenido que almacenen no cambia, siempre es constante.
A diferencia de las variables que se declaran con la palabra Dim, las Constantes se declaran con la palabra Const.
Ejemplo:
Const numero = 53
En la línea anterior he creado una constante, que la llamé numero y va a almacenar un número, y este valor, cuando se ejecute mi programa se mantendrá invariable. Un ejemplo:
En la siguiente línea se declaran 2 tipos de variables de tipo Integer llamadas num1 y num2. Luego se les asigna un valor a cada una y luego las sumamos, y mediante la función MsgBox, mostramos el resultado de esa suma.
Command1. Hacer dobleClick sobre el botón para que se abra la ventana de código de Visual Basic. Dentro del procedimiento Click pega este código:
Dim num1 As Integer
Dim num2 As Integer
num1 = 10
num2 = 20
'se mostrará un mensaje con la suma de las variables con el resultado 30
MsgBox num1 + num2
Al ejecutar el programa, puedes ver como se presenta una caja de mensaje con el resultado al sumar las 2 variables num1 y num2
3.- El ámbito de una variable se determina en el tiempo de que la variable se declara. En Microsoft Visual Basic para aplicaciones, los tres ámbitos disponibles para las variables son de procedimiento, módulo y pública.
Ámbito de procedimiento (local)
Una variable local con ámbito de procedimiento se reconoce sólo dentro del procedimiento en el que se declara. Puede declararse una variable local con una instrucción Dim o static.
Cuando se declara una variable local con la instrucción Dim, la variable permanece en existencia sólo mientras se ejecuta el procedimiento en el que se declara.
Por ejemplo, en las macros de ejemplo siguiente, "Ejemplo1" y "Example2", la variable X se declara en cada uno de los módulos. Cada variable X es independiente de la otra, sólo se reconoce la variable dentro de su procedimiento respectivo.
Sub Example1()
Dim X As Integer
' Local variable, not the same as X in Example2.
X = 100
MsgBox "The value of X is " & X
End Sub
Una variable local declarada con la instrucción static permanece en la existencia de todo el tiempo que se está ejecutando Visual Basic.
Por ejemplo, en el ejemplo TotalActualizado, la variable Accumulate retiene su valor cada vez que se ejecuta. La primera vez que se ejecuta el módulo, si escribe el número 2 , el cuadro de mensaje mostrará el valor "2". La próxima vez que el módulo se ejecute, si se especifica el valor 3, el cuadro de mensaje mostrará el valor total que 5. Sub RunningTotal() Static Accumulate ' Local variable that will retain its value after the module ' has finished executing. num = Application.InputBox(prompt:="Enter a number: ", Type:=1) Accumulate = Accumulate + num MsgBox "The running total is " & Accumulate End Sub
Ámbito de módulo Una variable de nivel de módulo permanece en existencia mientras Visual Basic se ejecuta hasta que se edita el módulo en el que se declara. Se pueden declarar variables de nivel de módulo con una instrucción Dim o Private en la parte superior del módulo encima de la primera definición de procedimiento. En el nivel de módulo, no es diferencia entre Dim y privado. Observe que las variables de nivel de módulo no se declara dentro de un procedimiento.
Observe que en Ejemplo4, cuando la macro intenta utilizar la variable C, el cuadro de mensaje está vacío. El cuadro de mensaje está vacío porque C es una variable local y no está disponible para Ejemplo4, mientras que son variables A y B. Dim A As Integer ' Module-level variable. Private B As Integer ' Module-level variable.
Sub Example1() A = 100 B = A + 1 End Sub
Sub Example2() MsgBox "The value of A is " & A MsgBox "The value of B is " & B End Sub
Sub Example3() Dim C As Integer ' Local variable. C = A + B MsgBox "The value of C is " & C End Sub
Sub Example4() MsgBox A ' The message box displays the value of A. MsgBox B ' The message box displays the value of B. MsgBox C ' The message box displays nothing because C was a local variable. End Sub
Ámbito público Las variables públicas tienen el ámbito más amplio de todas las variables.
4.- Reglas para nombrar: Las variables: De el nombre a la variable de acuerdo a lo que representa. El nombre debe ser lo más corto posible, pero sin dejar de representar lo que la variable guardará. No use espacios en el nombre de la variable. Por ejemplo, no use Horas Extras, sino HorasExtras. Comience el nombre de la variable con una letra. No utilice ningún símbolo que se use como operador matemático (+, -, *, etc.) en el nombre de la variable. La computadora reconocerá ese símbolo como operador matemático, convertirá la variable en dos o más variables y tratará la variable como una expresión matemática. Una vez incluya el nombre de una variable para representar un dato específico, debe usar exactamente ese mismo nombre en todos los lugares donde utilice ese dato. Sea consistente con el uso de las letras mayúsculas y minúsculas. Algunos lenguajes hacen diferencia entre estas letras, por lo que Edad no sería lo mismo que EDAD. Utilice los estándares de nombres establecidos en su lugar de trabajo. Estos estándares pueden cambiar dependiendo de la compañía u organización en donde trabaje. Las constantes Pueden tener un nombre, dependiendo del lenguaje de programación. En algunas compañías, el nombre se escribe en letras mayúsculas para diferenciarlas de las variables. Constantes con nombres tienen un lugar en la memoria de la computadora.
5.- Un procedimiento es un bloque de instrucciones de Visual Basic incluido entre una instrucción de declaración (Function, Sub, Operator, Get, Set) y una declaración End correspondiente. En Visual Basic, todas las instrucciones ejecutables deben incluirse en algún procedimiento. Llamar a un procedimiento Los procedimientos se invocan desde otras partes del código. Esto se conoce como una llamada a procedimiento. Cuando finaliza la ejecución de un procedimiento, éste devuelve el control al código que lo invocó, que recibe el nombre de código de llamada. El código de llamada es una instrucción o una expresión contenida en una instrucción, que hace referencia al procedimiento por su nombre y le transfiere el control. Como se declara: En Visual Basic lo haces por medio de variables ejemplo: C1 es mi variable C1=val(text1) aquí el procedimiento R es otra variable R=C1+10 text2=R Como es orientada a objeto basta con asignar la respectiva codificación a cada uno de los componentes de la aplicación (labels, textbox, datas), solo se asocia un valor al objeto el: a=text1.text , b=text2.tex , text3.text=a+b Volver de un procedimiento Los procedimientos devuelven el control al código de llamada cuando finalizan su ejecución. Para ello, puede utilizar instrucciòn Return, la instrucción Exit apropiada para el procedimiento o la instrucción End del procedimiento. El control se devuelve al código de llamada, a continuación del punto de la llamada al procedimiento. · Con una instrucción Return, el control vuelve inmediatamente al código de llamada. No se ejecutan las instrucciones siguientes a la instrucción Return. Puede tener más de una instrucción Return en el mismo procedimiento. · Con una instrucción Exit Sub o Exit Function, el control vuelve inmediatamente al código de llamada. No se ejecutan las instrucciones siguientes a la instrucción Exit. Puede tener más de una instrucción Exit en el mismo procedimiento, y puede mezclar las instrucciones Return y Exit en el mismo procedimiento. · Si un procedimiento no incluye instrucciones Return o Exit, concluye con una instrucción End Sub o End Function, End Get o End Set a continuación de la última instrucción del cuerpo del procedimiento. La instrucción End devuelve el control inmediatamente al código de llamada. Puede tener sólo una instrucción End en un procedimiento.
¡Muchas gracias! Sus comentarios nos ayudarán a mejorar los contenidos de soporte. Para más opciones de asistencia, visite la página de Ayuda y soporte técnico. |