Datos personales

Mi foto
Catedrático: Patricia Arieta Melgarejo Jefa de Carrera de la Licenciatura en Sistemas Computacionales Administrativos.

Caracteisticas de un analista

Check out this SlideShare Presentation:

Ciclo2

Check out this SlideShare Presentation:

Ciclo de vida

Check out this SlideShare Presentation:

Ciclo de vida

Check out this SlideShare Presentation:

Clasificación de los requerimientos

Check out this SlideShare Presentation:

Herramienta case

Check out this SlideShare Presentation:

Hcase

Check out this SlideShare Presentation:
Hcase
View more presentations from FSILSCA.

Jackson

Check out this SlideShare Presentation:

Libro Herramientas Case

Check out this SlideShare Presentation:

Recursos de los estudios de factibilidad

Check out this SlideShare Presentation:

Requerimientos 2

Check out this SlideShare Presentation:

Analisis

Check out this SlideShare Presentation:

Modelos del ciclo de vida de software

Los modelos de ciclo de vida de software es una lista de las actividades que ocurren durante el desarrollo de software, en el cual se intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.



Codificar y Corregir

 Este es un modelo poco útil, pero bastante común. Al no haberse seleccionado explícitamente otro modelo, por omisión se estará utilizando éste.
Cuando se utiliza se empieza con una idea general de lo que se necesita construir, y se puede o no tener una especificación formal; se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.

Observaciones al modelo codificar y corregir

Puede resultar útil para proyectos pequeños que se intentan liquidar poco después de ser construidos, es decir, para programas pequeños de demostración de conceptos, demostraciones de duración corta o prototipos desechables.
No tiene cabida en un proyecto de desarrollo rápido, excepto para estos pequeños proyectos arriba señalados
Es un modelo no formal que se utiliza normalmente porque es simple, pero no porque funcione bien.

Análisis Estructurado

El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de la división del sistema en componentes y la construcción de un modelo del sistema. El método incorpora elementos tanto de análisis como de diseño. El modelo de análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación.
No se establece como se cumplirán los requerimientos o la forma en que se implantarán la aplicación. Más bien permiten que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento etc.)

Cascada Pura

Es el predecesor de todos los modelos de ciclo de vida y ha servido de base para otros modelos. En el modelo de cascada pura  un proyecto progresa a través de una secuencia ordenada de etapas, partiendo desde su concepto inicial hasta la prueba del mismo, así el proyecto realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente.

Observaciones al modelo cascada pura

Es el modelo más conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias, otros modelos sin embargo, proporcionan una velocidad de desarrollo superior a éste.
Los inconvenientes del modelo hacen que sea, a menudo, poco apropiado para un proyecto de desarrollo rápido, incluso en los casos en los que las ventajas del modelo superan los inconvenientes, los modelos de cascada modificada pueden funcionar mejor.

Espiral

Es un modelo orientado a riesgos que divide un proyecto en miniproyectos, cada miniproyecto se centra en uno o más riesgos importantes hasta que todos éstos estén controlados.
El concepto “riesgo” puede referirse a requerimientos y arquitecturas poco comprensibles, a problemas de ejecución importantes o a problemas con la tecnología subyacente. Una vez que se han controlado todos los riesgos importantes, el modelo finaliza del mismo modo que el modelo de ciclo de vida en cascada. 

Observaciones al modelo espiral

El modelo de espiral es un modelo de ciclo de vida orientado a riesgos, el cual se puede combinar con otros modelos de ciclo de vida.
La principal ventaja de este modelo es que mientras los costos suben, los riesgos disminuyen.

Cascadas Modificadas

El mayor problema del modelo de cascada pura es que trata las fases del ciclo de vida como etapas secuenciales disjuntas, pero, en contraste, permite corregir los inconvenientes más importantes en el modelo de cascada pura con pequeñas modificaciones:
Puede modificarse de forma tal que las etapas se solapen.
Se puede reducir el énfasis sobre la documentación.
                        Se puede permitir más regresión. 

Variantes del modelo de cascadas modificadas

Cascada con fases solapadas

Puede evitar algunos inconvenientes del modelo de cascada pura al solapar sus etapas, por ejemplo, sugiere que se debería tener bien hecho el diseño global y quizás a medio hacer el diseño detallado antes de considerar completo el análisis de requerimientos, no obstante, puede reducir sustancialmente la documentación necesaria entre etapas.

Cascada con subproyectos

Puede permitir la ejecución de algunas de las tareas de la cascada en paralelo (subproyectos), siempre que se haya realizado una cuidadosa planificación.

Cascada con reducción de riesgos

Incorpora una espiral en lo alto de la cascada para controlar el riesgo de los requerimientos, y una espiral para las demás etapas de desarrollo. A este nivel es posible desarrollar un prototipo de interfaz de usuario, tener entrevistas con los usuarios, observar cómo los usuarios interactúan con algún sistema previo, y utilizar otros métodos que se consideren apropiados para la identificación de los requerimientos.
Desventajas de las variantes

Modelo de cascada con fases solapadas

Debido al solapamiento entre las etapas, los hitos son más ambiguos, y esto hace más difícil trazar el progreso correctamente, además la realización de actividades en paralelo puede suponer una mala comunicación, suposiciones incorrectas e ineficacia.

Modelo de cascada con subproyectos
Existe presencia de interdependencias imprevistas.

Modelo de cascada con reducción de riesgos
Ninguno.

Prototipos de Sistemas

Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño.
La construcción de prototipos es más eficaz bajo las circunstancias correctas sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.
El prototipo es un sistema que funciona –no solo una idea en el papel- , desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software, que acepta entradas, realiza cálculos, produce información ya sea impresa o en pantalla, o que lleva a cabo otras actividades significativas.
            Los usuarios evalúan el diseño de información generada por el sistema y deben esperarse cambios a medida que el sistema es utilizado.

            Las razones por las cuales se deben utilizar los prototipos de sistemas son que los requerimientos de información no siempre están bien definidos; los prototipos permiten evaluar situaciones extraordinarias, donde los encargados de diseñar sistemas no tienen información ni experiencia, ya que en realidad es un modelo piloto o de prueba, y es un sistema que funciona debido a que está diseñado para ser modificado con facilidad.

Prototipado Evolutivo

Es un modelo de ciclo de vida en el que se desarrolla el concepto del sistema a medida que avanza el proyecto.
Normalmente se comienza desarrollando los aspectos más visibles del sistema, posteriormente se presenta la parte ya desarrollada del sistema al cliente y se continúa el desarrollo del prototipo en base a la realimentación que se recibe del cliente. Finalmente, el ciclo continúa hasta que el prototipo se convierte en el producto final de ingeniería.
Es conveniente utilizar el prototipado evolutivo cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de los requerimientos, cuando ni el analista ni el cliente identifican de forma apropiada el área de aplicación o cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a utilizar.

Ciclo en V

Uno de los inconvenientes del modelo en cascada es que las pruebas del software son dejadas al final del desarrollo.
El ciclo de vida en V, es una variación del modelo en cascada que trata este problema, toma su nombre de la forma en la cual se visualiza y es una evolución del modelo en cascada en el cual se realizan actividades en paralelo y facilita las pruebas del sistema. Así, se basa en la premisa de que las pruebas de calidad no se deben dejar al final, sino realizarse a lo largo del proceso.

Entrega por Etapas o Implementación Incremental

El sistema se muestra al cliente en etapas refinadas sucesivamente.
A diferencia del modelo de prototipado evolutivo, se conoce exactamente qué es lo que se va a construir cuando se procede a construirlo.
Lo que hace diferente a este modelo es que el sistema no se entrega como un todo al final del proyecto, sino que éste se entrega por etapas sucesivas a lo largo del proyecto.

Diseño por planificación

Es similar al modelo entrega por etapas, la diferencia radica en que no siempre se conoce al principio si se tendrá el producto para la última entrega.
Se pueden tener cinco etapas planificadas, pero sólo se llega a la tercera etapa debido a que se tiene una fecha límite que no se puede cambiar.
Uno de los elementos críticos de este modelo es priorizar los requerimientos y planificar sus etapas de tal forma que las primeras contengan los requerimientos de mayor prioridad, y los requerimientos de baja prioridad se dejan para más tarde.

Entrega Evolutiva

                        Es un modelo que se encuentra entre el prototipado evolutivo y la entrega por etapas: se desarrolla una versión del producto, se muestra al cliente, se refina el producto en función de los comentarios del cliente. El parecido entre ambos modelos depende de hasta qué punto se lleva a cabo una planificación para adaptarse a las solicitudes de los clientes.
Si se planifica para adaptarse a la mayoría de las solicitudes, la entrega evolutiva se parecerá más al prototipado evolutivo, pero si se planifica para adaptarse a pocas solicitudes de modificación, la entrega evolutiva se aproximará a la entrega por etapas.

Tablas decision

Check out this SlideShare Presentation:

Tecnicas de documentacion

Check out this SlideShare Presentation:

Técnicas y herramientas de documentación

Check out this SlideShare Presentation:

Modelo y Técnicas de documentación para el desarrollo de los Sistemas

Las lecturas presentadas detallan diferentes modelos y técnicas de documentación para el desarrollo de Sistemas ya que en la actualidad, no existe una metodología aceptada como estándar para el proceso de sistematización y automatización de una organización. De acuerdo a la investigación realizada por Leymann & Altenhuberen  en 1994, se analizaron varias metodologías que se utilizan para el desarrollo de sistemas de información las cuales tienen diferentes procedimientos para el análisis de una organización.



Flujograma

El flujograma es una "representación gráfica de una secuencia de pasos en una tarea o actividad". A esta representación gráfica se le ha nombrado de diferentes formas; diagrama de bloque, diagrama de flujo, diagrama lógico, gráfica de sistema, diagrama de proceso, gráfica de procedimiento y gráfica lógica. Esta diferencia en nombres refleja una falta de uniformidad en la nomenclatura y también en la influencia que ejercen los intereses particulares de los usuarios especializados. Por ejemplo, antes del advenimiento de las computadoras el nombre de flujograma fue utilizado por analistas de sistemas para describir el flujo de los documentos en una organización.

El flujograma es una de las pocas herramientas gráficas que está catalogada como de "propósito general". (Leslie, 1986) Esta se puede utilizar para representar o crear modelos del flujo o movimiento de materiales, documentos, datos, procesos, operaciones, procedimientos y actividades. (Licker, 1987) Algunos de los flujogramas mas utilizados en la actualidad son : flujograma de sistemas, diagrama Warnier-Orr, diagrama de flujo de datos, diagrama de flujo de materiales y documentos, flujograma de proceso, gráfica Gantt, etc.. (Licker, 1987).



Notación Yourdon

El diagrama de flujo de datos conocido en inglés "Data Flow Diagram" se utiliza para representar los procesos y el flujo o movimiento de los datos a través de estos procesos. La transformación de los datos, desde la entrada hasta la salida, a través de los procesos, puede describirse lógicamente y de forma independiente de los componentes físicos de un sistema. Existen dos tipos de diagramas de flujo de datos: uno identificado como el físico y otro como el lógico. El diagrama de flujo de datos físico muestra que tareas se llevan a cabo y como éstas son ejecutadas. Algunas de las características que se incluyen en este
tipo de diagrama son: nombre de las personas que ejecutan la tarea, nombre y/o número de formas o documentos, nombre de los departamentos, archivos, equipo y otros aparatos utilizados, localizaciones y nombres de los procedimientos. Senn recomienda el uso de este tipo de diagrama por tres razones: es mas fácil poder entender la interacción entre los componentes físicos de un sistema que entender los procedimientos o políticas utilizadas para llevar a cabo cualquier proceso, facilita la comunicación con el personal y ayuda a validar el modelo creado con el usuario. El diagrama de flujo de datos lógico se dirige a definir "el flujo de datos entre los procesos sin tomar en consideración el equipo utilizado, los nombres de las personas, los números de las formas y otros aspectos de carácter físico". Existen dos notaciones comúnmente utilizadas para el análisis del flujo de los datos, una desarrollada por Edward Yourdon y la otra por Chris Gane y Trish Sarson.



HIPO (Hierarchical Input-Process-Output)

El diagrama jerárquico insumo-proceso-producto mejor conocido en inglés por las siglas HIPO es una técnica diagramática que utiliza una serie de diagramas para mostrar el insumo, producto y las funciones de un sistema. Este muestra que el sistema hace pero no como lo hace. Existen tres clases de diagramas HIPO: tabla de contenido visual, los diagramas generales y los detallados. La tabla de contenido visual es el nivel superior del diagrama de HIPO. Es una estructura en forma de árbol que muestra los componentes generales de un sistema. No ofrece información de control ni describe los datos en el sistema. En el diagrama general se describen los insumos, los procesos y productos de los componentes principales del sistema.

El propósito es "proveer de un conocimiento general de una función".  El diagrama detallado provee de la información necesaria para entender cuales son los insumos, procesos llevados a cabo y el producto de un componente funcional.




Warnier Orr

Este diagrama se utiliza para representar gráficamente la estructura jerárquica de un sistema, programa o estructura de datos. Obtuvo su nombre de sus dos principales proponentes Jean-Dominique Warnier y Ken Orr.

Este diagrama se construye horizontalmente a través de una página utilizando llaves o "brackets", en lugar de utilizar bloques como en los diagramas anteriores. 

Tablas de Decisión

Las tablas de decisión son herramientas que se utilizan:

a)    En la etapa de análisis de sistemas: para efectuar una  representación  gráfica  sim-
plificada de los procesos lógicos que hayan sido relevados durante la  investigación detallada, a efectos de analizar si se adecuan o no a los requerimientos del sistema.

b)    En la etapa de diseño de sistemas: para representar gráficamente procesos lógicos
creados para satisfacer las necesidades del sistema bajo estudio.

c)    Aisladamente, es decir,en tareas que no tengan que ver con el estudio de sistemas,
para la representación simplificada de procedimientos específicos que sirvan de apoyo para una interpretación correcta del mismo y su posterior ejecución
(procedimientos legales, impositivos, laborales, previsionales, aplicación de normas
técnicas).

Son un medio de comunicación entre los Analistas y los usuarios y entre los Analistas y los Programadores de computación. También son un instrumento de programación ya que facilitan en gran medida la tarea del Programador, que debe convertir las condiciones y acciones de las tablas en programas de computación.

Existen dos tipos de Tabla:

Tablas de entrada limitada

Sus principales características son:

a) Las condiciones y las acciones figuran expresadas en forma completa.
b) Los valores asignados a las condiciones solo pueden ser SI o NO. Por tal
motivo las condiciones se las expresa en forma de preguntas, las cuales sólo podrán ser respondidas afirmativa o negativamente.
c) Los valores asignados a las acciones pueden ser: X (la acción debe ser ejecutada) o “blanco” (la acción no debe ser ejecutada).
d) La cantidad de reglas surge de calcular “2 a la n”, donde n es la cantidad de
condiciones.
Tablas de entrada extendida

Sus principales características son:

a) Se utilizan cuando hay variables que pueden asumir más de dos valores. En
este caso deberá considerarse que cada variable se desdobla en tantas condiciones como valores diferentes pueda asumir la misma. En consecuencia, en lugar de indicar SI o NO, van a escribirse todos los  valores que pueda tener cada condición. Dichos valores pueden describirse mediante abreviaturas, debiendo indicarse al pie o a un costado de la tabla los significados de cada una. En aquellos casos en que los valores de una condición fueran indiferentes para la realización de determinadas acciones, es aconsejable dejar en blanco la celdas correspondientes a los valores de esa condición; esto reducirá la cantidad de reglas de decisión de la tabla.


Presentacion de la información

Check out this SlideShare Presentation:

Información en el Sistema de Comunicación

El Matemático Norbert Weiner desarrolló la teoría de la información como resultado de un estudio de cibernética. Esta teoría se aplica al sistema de comunicación mecánica y eléctrica, con ella se pretende lograr la comprensión acerca de la naturaleza de la información.


El Modelo de un sistema de comunicación tiene como propósito hacer llegar a un destino un mensaje seleccionado en la fuente.



Elementos

Transmisor:    manipula símbolos codificados para enviar al receptor.

Mensaje:         proviene del transmisor y este debe estar codificado para pasar por los   
                        canales de comunicación.

Receptor:        Decodifica símbolos recibidos antes de pasar al destinatario.

Canal:                         Conductor de mensaje codificado

Imperfección:                    ruido=interferencia no predecible   y   distorsión=operación conocida
                                                                                                                                 intencional