Definición de sistema de información basado en computadoras
Def:
IS es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software.
Elementos:
*Métodos: indican cómo construir técnicamente el software, incluyendo criterios de calidad.
*Herramientas: proveen el apoyo a los métodos y constituyen un soporte al desarrollo. Estas herramientas son conocidas como “Herramientas CASE” y pueden ser manuales, semiautomáticas y completamente automáticas.
*Procedimientos: constituyen al vínculo entre los métodos y las herramientas, tienen por objeto facilitar el desarrollo racional y oportuno del producto.
– ACTIVIDADES DE LA INGENIERÍA DE SOFTWARE:
Actualmente para desarrollar software se necesita: Analizar el problema hasta su total comprensión;Diseñar el software que cumpla las expectativas;Programarlo, probarlo y Mantenerlo hasta que se decida su retiro. Cada una de estas actividades son abordadas por la IS a través de sus etapas:
*Análisis de requisitos: consiste en extraer los requisitos de un producto software que se plasman en el documento de Especificación de Requisitos. La captura, análisis y especificación de requisitos es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales.
*Especificación: es la tarea de escribir detalladamente el software a ser desarrollado. Los requisitos se suelen especificar en lenguaje natural, se expresan de forma individual, se organizan de forma jerárquica, a menudo, se enumeran.
*Diseño y arquitectura: se refiere a determinar cómo funcionará el software de forma general sin entrar en detalles.
*Programación: consiste en reducir el diseño a código, no demanda mayor trabajo ni es complicado.
*Prueba: consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema.
*Mantenimiento: consiste en mantener y mejorar el software para solventar errores descubiertos y tratar con nuevos requisitos.
– EL PROCESO DE DESARROLLO DE SOFTWARE:
Un proceso software es un conjunto de actividades y resultados asociados que conducen a la creación de un producto software.
Proceso genérico de desarrollo de software
1- Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir
2.- Diseño del sistema: Construye el software de acuerdo a la especificación
3.- Implementación: Codificación y tareas relacionadas
4.- Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente
5.- Instalación: Entregar el sistema al usuario y asegurar su operatividad
6.- Evolución y Mantenimiento:
cambiar/adaptar el software según las demandas; reparar fallos en el sistema cuando sean descubiertos.
– CICLO DE VIDA Definición:
Conjunto de estados por lo que pasa el software o producto.Ciclo de transformaciones que el software/producto sufre a lo largo de su vida.
MODELOS CICLO DE VIDA DEL SOFTWARE:
Cascada:
el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas y las actividades dentro de cada fase a la satisfacción de las metas de cada fase. Las fases son: requisitos, diseño, codificación, prueba y operación.
Desarrollo Incremental:
es el proceso de construir una implementación parcial del sistema global y posteriormente ir aumentando la funcionalidad del sistema. Debe construirse de tal modo que facilite la incorporación de nuevos requisitos. Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El primer incremento a menudo es un producto esencial (núcleo). A partir de la evaluación se planea el siguiente incremento y así sucesivamente. El proceso se divide en 4 partes: análisis, diseño, código y prueba.
Desarrollo con Prototipado:
consiste en construir un prototipo que ayude a comprender los requisitos del usuario y de ese modo contrarrestar el problema de la congelación de requisitos mal comprendidos.El objetivo es mejorar el prototipo con el paso del tiempo hasta que se acomode a las necesidades de los usuarios, por medio de un proceso iterativo que consiste en probar y afinar constantemente el prototipo hasta que cumpla su objetivo. El proceso se resume en 4 pasos: identificar los requerimientos básicos del usuario, desarrollar prototipo inicial, usar el prototipo, revisión y mejora del prototipo. Existen 3 tipos de prototipos: maqueta, prototipo Desechable, prototipo evolutivo.
Espiral:
incorpora un nuevo elemento llamado «Análisis de Riesgos». Las actividades son: planificación, análisis de Riesgos, ingeniería, evaluación del Cliente. Consiste en iterar alrededor de un espiral dividido en 4 cuadrantes, comenzando en el centro y siguiendo hacia el exterior, donde se van construyendo sucesivas versiones del software, cada vez más completas. En el primer cuadrante se determinan objetivos, alternativas y restricciones. En el segundo cuadrante se analizan e identifican los riesgos. En el cuadrante tercero se incorporan incrementalmente las etapas del ciclo de vida tradicional en cada ciclo de la espiral. En el cuarto cuadrante el cliente evalúa el trabajo de ingeniería de esa espiral y sugiere modificaciones. Basándose en los comentarios del cliente, se produce la siguiente fase de planificación y de análisis de riesgos. Al finalizar el análisis de riesgo, se debe tomar la decisión de seguir adelante o no con el proyecto.
DEFINICIÓN DE INGENIERÍA DE REQUISITOS:
La ingeniería de requisitos, es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático.
PUNTOS A CONSIDERAR DURANTE LA INGENIERÍA DE REQUISITOS:
Objetivos del negocio y ambiente de trabajo: Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. El nuevo sistema cambiará el ambiente de trabajo, sin embargo, los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en producción; también ocurren cuando cambia el ambiente que lo rodea.
*Punto de vista de los clientes: muchos sistemas tienen diferentes tipos de clientes los cuales tienen necesidades diferentes y puntos de vista diferentes, los cuales pueden ocasionar problemas tales como datos redundantes, inconsistencia y ambigüedad.
*Barreras de comunicación: la IR depende de una intensa comunicación entre clientes y analistas de requisitos, sin embargo; existen problemas que no pueden ser resueltos mediante la comunicación. Para ello se debe abordar nuevas técnicas operacionales que ayuden a superar dichos problemas.
*Evolución e integración del sistema: pocos sistemas son construidos desde cero, sino que parten de un proyecto de sistema ya existente, por lo tanto los analistas de requisitos deben comprender esos sistemas, que por lo general son una integración de componentes de varios proveedores
*Documentación de requisitos: los documentos de ingeniería de requisitos son largos. La mayoría están compuestos de cientos o miles de páginas por ello las personas se encuentran con dificultades para comprenderlos. Esto causa problemas y errores que no son detectados hasta después de haberse construido el sistema.
– DEFINICIÓN DE REQUISITOS:
un requisito es una condición o capacidad que debe satisfacer un sistema.
– NIVELES DE DESCRIPCIÓN DE LOS REQUISITOS:
*A nivel de negocio: son los que representan objetivos de alto nivel para la organización o el cliente que requiere el producto.
*A nivel de usuario: son los que describen tareas que los usuarios deben estar en capacidad de cumplir con el producto de software que se está describiendo, son conocidos como requisitos del usuario.
*A nivel de tarea: el sistema debe ejecutar cuando el usuario opera en él. Describe funcionalidades necesarias para satisfacer tareas específicas, necesidades operacionales y grupos de usuarios.
*A nivel de sistema: función en la que debe ser construida para que el producto realice la tarea según las necesidades del sistema.
Sirve como base para realizar la arquitectura, diseño y planes del sistema.
– TIPOS DE REQUISITOS:
Requisitos funcionales
Describen las tareas las tareas que el sistema debe realizar. También son declaraciones de los servicios y funciones que proveerá el sistema. Ejemplo: “El sistema de control medirá la temperatura y la humedad de la habitación”
Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, resultan deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad: Tiempos de respuesta, carácterísticas de usabilidad, etc. Ejemplo: Presentaciones: “La captura del video debe realizarse al menos a 12 fps”
– CLASIFICACIÓN DE REQUISITOS Y CONCEPTOS BÁSICOS DE IEEE:
#Requisitos de adaptación: especifican los rasgos que deben modificarse para adaptar el software a una instalación particular.
#Requisitos de interfaces externos: describen, de modo detallado, todas las entradas y salidas del sistema.
#Requisitos funcionales: definen las acciones elementales que deben realizarse sobre el software aceptando y procesando un conjunto de entradas y procesando y generando un conjunto de salidas.
#Requisitos de ejecución: describen los requisitos estáticos y dinámicos que se dan lugar en el software
#Requisitos lógicos de las bases de datos: especifican los requisitos lógicos para cualquier información que es almacenada en un banco de datos.
#Requisitos de restricciones de diseño: especifican los requisitos derivados de los estándares existentes.
#Requisitos relacionados con atributos del sistema: existen una serie de atributos, tales como fiabilidad, disponibilidad, seguridad, mantenimiento y portabilidad.
ASPECTOS ESPECÍFICOS PARA DETERMINAR LOS REQUISITOS:
Entendimiento de los Procesos, información producida, tiempo y controles:
Los desarrolladores o analistas estructuran su investigación y buscan respuestas a las siguientes 4 preguntas:
¿Cuál es el proceso básico? ¿Qué datos se utilizan o se producen durante este proceso? ¿Cuáles son los límites impuestos por tiempo o cantidad de trabajo? ¿Qué controles de desempeño se utilizan?
Entendimiento del proceso
Se hacen preguntas que al contestar proporcionan antecedentes de los datos fundamentales y de las descripciones del sistema, estas son:
¿Cuál es el propósito de esta actividad? ¿Cuáles son los pasos que se realizan? ¿Quién los realiza? ¿Cuánto tiempo consume? ¿Quién utiliza la información resultante?
Identificación de los datos utilizados y la información producida
El analista necesita encontrar que datos se utilizara para realizar la actividad.
Determinación del tiempo del proceso y la cantidad
Diferentes actividades se realizan con distinta frecuencia, por lo tanto, el analista debe tener en cuenta esto. Algunas duran poco, otras se presentan poco, pero requieren gran tiempo.
Identificación de controles
El analista deber determinar durante la etapa de análisis los métodos de control.
– ELICITACIÓN DE REQUISITOS. DEFINICIÓN:
es el proceso de adquirir todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema.
– MODELOS EN LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE:
-Obtener información sobre el dominio del problema y el sistema actual: está tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual.
-Preparar y realizar las reuniones de elicitación/negociación: de acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos.
-Identificar/revisar los objetivos del sistema: A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos.
-Identificar/revisar los requisitos de información: a partir de las tareas 1 y 2, y los objetivos en la 3, en está tarea se debe identificar, o revisar si existen conflictos, que información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar , así como qué restricciones o reglas de negocio debe cumplir dicha información.
-Identificar/revisar los requisitos funcionales: de acuerdo a las tareas anteriores se debe identificar los actores que interactuaran con el sistema, los requisitos funcionales, así como su especificación correspondiente.
-Identificar/revisar los requisitos no funcionales: con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar.
TÉCNICAS Y HERRAMIENTAS DE RECOLECCIÓN DE DATOS. (Entrevista
Cuestionario )
#Entrevista: se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente. El analista puede entrevistar al personal en forma individual o grupal.
Recabar datos mediante la entrevista:
es una forma de conversación no de interrogación y se realiza con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema(Gerente de la empresa o personal seleccionado).
Determinación del tipo de entrevista:
podemos diferenciar dos tipos:
Entrevista abierta:
sirve para obtener información de índole general, ya que se realiza una sesíón de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de está modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde.
Entrevista estructurada
Utiliza preguntas estandarizadas. El formato de respuesta para las preguntas puede ser abierta o cerrada; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar
Selección de entrevistados:
dado que se seleccionara un número limitado de personas, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Por lo general sólo se aplica la entrevista a la gerencia o personal de supervisión.
Realización de la entrevista
Problemas fundamentales por lo que hay que preocuparse:
existen muchos problemas qué pueden surgir, los más comunes son los siguientes:
Entrevistar a las personas equivocadas en el momento equivocado.Hacer las preguntas equivocadas y obtener las respuestas equivocadas.Crear fricciones entre ambas partes.
Reglas para hacer entrevistas:
Desarrollar un plan global de la entrevista.Asegurarse de contar con aprobación para hablar con los usuarios.Planear la entrevista para usar de manera efectiva su tiempo.Usar herramientas automatizadas cuando sea apropiado, pero no abusar.Tratar de juzgar qué información le interesa más al usuario
#Cuestionario: proporciona una alternativa muy útil para la entrevista; sin embargo, existen ciertas carácterísticas qué pueden ser apropiadas en algunas situaciones e inapropiadas en otras. Al igual qué las entrevistas, deben diseñarse cuidadosamente para una máxima efectividad.
Recabar datos mediante cuestionarios:
puede ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del sistema, debido a esto, no es posible observar las expresiones de quienes responden a los cuestionarios. En la mayor parte de los casos el analista no verá a los qué responden. Ya qué la implementación se realiza en un gran número de personas es muy raro obtener una respuesta total
Selección de formas para cuestionarios:
existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados, se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas.
Cuestionario Abierto:
se aplica cuando se quieren conocer los sentimientos, opiniones y experiencias generales.
-DEFINICIÓN DE UN MODELO:
es una abstracción de algo cuyo objetivo es comprenderlo antes de construirlo.
– OBJETIVOS O VENTAJAS DE UN MODELO O DEL MODELADO:
*Probar una entidad física antes de construirla:
consiste en probar modelos a escala permitiendo de está forma simular el funcionamiento del mismo para obtener información excesivamente difícil ser medida en un modelo físico, haciendo posible corregir desde un principio errores.
*Comunicación con el cliente
Los modelos construidos se presentan a los clientes. Las maquetas son productos que imitan parte del comportamiento externo del sistema o quizás el comportamiento completo
*Visualización:
se visualiza el modelo en ejecución y, si es necesario, se realizan las modificaciones correspondientes antes de pasar a desarrollarlo.
*Reducción de la complejidad
Los modelos reducen la complejidad, separando un pequeño número de cosas importantes para tratarlas cada vez.
– CONCEPTO DE ARQUITECTURA DE SOFTWARE:
es la descripción de los elementos (subsistemas y componentes) que forman el sistema y de las interrelaciones entre ello, también es una forma de representar sistemas complejos mediante el uso de la abstracción.
– MODELADO LÓGICO Y MODELADO FÍSICO DE SISTEMAS EN LA OO:
Diagrama de Componentes:
se utilizan para representar la arquitectura lógica de un sistema, en componentes de software, sus interfaces y dependencias. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Las relaciones de dependencia se utilizan para indicar qué un componente utiliza los servicios de otro componente.
Diagrama de Despliegue: se utiliza para representar la arquitectura física sobre la qué un sistema software es desplegado, describe tanto dispositivos físicos como elementos software. Se puede describir por medio de nodos y asociaciones. Los nodos son objetos físicos qué existen en tiempo de ejecución y se conectan entre sí por medio de asociaciones de comunicación.
MULTIPLICIDAD DE UNA RELACIÓN Y SUS TIPOS:
especifica el número de instancias de una clase qué pueden estar relacionadas con una única instancia de una clase asociada.
CarácterÍSTICAS DE LOS OBJETOS:
Identidad:
quiere decir que los datos están cuantificados en entidades discretas y tangibles denominadas objetos (párrafo de documento, reina blanca de ajedrez). Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o conceptuales, como la política de planificación en un sistema operativo. Dos objetos son distintos aun cuando los valores de todos sus atributos sean iguales.
Clasificación:
Significa que los objetos con la misma estructura de datos (atributos) y comportamientos se agrupan para formar una clase. Una clase es una abstracción que describe propiedades importantes para una aplicación y que ignora el resto. Además, describe un conjunto posiblemente infinito de objetos individuales.
Se dice que cada objeto es una instancia de su clase, la cual posee su propio valor para cada uno de los atributos, pero comparte los nombres de los atributos y comportamientos con las demás instancias.
Polimorfismo:
Significa que una misma operación puede comportarse de modos distintos en distintas clases. Una operación es una acción que se aplica a un objeto. Una implementación de una operación por parte de una clase es lo que se denomina un método.
Herencia:
Es compartir atributos y operaciones entre clases tomando como base una relación jerárquica. Se puede definir una clase que después producirá subclases, las cuales heredan todas las propiedades de su superclase y añaden sus propiedades. No es necesario repetir las propiedades de las superclases en cada subclase.
-DIAGRAMA DE CLASES:
es una plantilla para describir muchas instancias de datos posibles.
– DIAGRAMA DE INSTANCIAS:
describe la forma en qué un cierto conjunto de objetos se relacionan entre sí.
– LA RELACIÓN DE AGREGACIÓN:
es la relación “parte-todo” en la cual los objetos qué representan los componentes de algo se asocian a un objeto qué representa el ensamblaje completo
– ROLES DE UNA ASOCIACIÓN/RELACIÓN:
Un rol es un extremo de una asociación. Una asociación binaria posee dos roles, cada uno de los cuales pueden poseer un nombre de rol que identifica de forma única un extremo de una asociación. El uso de nombre de rol proporciona una forma de recorrer las asociaciones desde un objeto de un extremo sin mencionar, explícitamente, la asociación.
– DEFINIR LA METODOLOGÍA ICONIX FASES:
es un proceso simplificado qué unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto, está adaptado a los patrones de UML, dirigido por casos de uso y es un proceso iterativo e incremental.
– ACTIVIDADES DE CADA FASE E HITO:
Análisis de requerimiento:
Identificar objetos del dominio y relaciones de agregación y generalización;Prototipo rápido;Identificar casos de uso;Organizar casos de uso en grupos;Asignar requerimientos Funcionales a casos de uso y objetos;HITO: revisión de requerimiento.
Análisis de diseño preliminar:
Escribir descripciones de casos de uso;Cursos básicos y alternativos;Análisis de robustez;Identificar grupos de objetos qué realizan el escenario;Actualizar diagramas de clases del dominio;Finalizar diagramas de clases;HITO: revisión del diseño preliminar;De usuario hacia sistema;De datos hacia el sistema.
Diseño:
Asignar comportamiento;Para cada caso de uso:Identificar mensajes y métodos.Dibujar Diagramas de secuencia.Actualizar clases.(opcional) Diagrama de colaboración.(opcional) Diagrama de estados.Terminar modelo estático.Verificar cumplimiento de requerimientos.HITO: revisión crítica del diseño.
Implementación:
Producir diagramas necesarios;Despliegue;Componentes;Escribir el código;Pruebas de unidad e integración;Pruebas de sistema y aceptación basadas en casos de uso.HITO: entrega del sistema
– ANÁLISIS DE ROBUSTEZ:
Sirve para
-Comprobar la sanidad: revisa las ideas de los casos de uso..Comprobar la entereza: asegurar qué en los casos de uso se cubra el camino básico y los posibles caminos alternativos..Descubrir objetos: los nuevos objetos qué se descubren deben llevarse al modelo del dominio, y esté también es el tiempo correcto par agregar algunos atributos clave a sus clases más significantes..Diseño preliminar: los diagramas son la primera vista del nuevo sistema
Los elem Diagrama son:Objetos fronterizos (de límite): objetos con los cuales puede interactuar el usuario.De entidad: generalmente objetos del modelo de dominio.
De control (controles): intermediarios entre los fronterizos y de entidad.
Actor: es el usuario quien hace uso del sistema en sí y se relaciona de forma directa con los elementos fronterizos.