ingeniería software

SISTEMAS DE INFORMACIÓN

SISTEMAS DE INFORMACIÓN

Control u ordenación de elementos organizados para llevar acabo algún método, procedimiento o control mediante el proceso de la información.

ANÁLISIS Y DISEÑO

Se refiere al proceso de examinar la situación de una empresa con el propósito de mejorar con métodos y procedimientos más adecuados.

COM

PON

ENTES

Análisis Diseño

Proceso de clasificación e interpretación de hechos.

Diagnóstico del problema

Empleo de la información para recomendar mejoras al sistema actual

Especifica las características del producto terminado

Establece como alcanzar el objetivo

ACTIVIDADES Análisis de sistemas:

Análisis y diseño de sistemas:

Análisis, diseño y programación de sistemas:

Análisis del sistemas

Actividad:Persona encargada:

Reúne la información y determina los requisitos

Los analista no son responsables del sistema

Analista de Información

Análisis y diseño del sistem

as


Tiene la responsabilidad adicional de diseñar el nuevo sistema

Diseñador de sistemas

Diseñador de aplicaciones

Análisis, diseño y program

ación del sistemas


Desarrolla las especificaciones de diseño

Analiza el software necesario para implementar el diseño

Analista programador

ELEMENTOS DE UN SI Software Hardware Gente Base de datos Documentación Procesamiento Control

ELEMEN

TOS D

E UN

SIsoftware

Hardware

Programas

Estructura de datos y documentación asociada para realizar el método lógico

Dispositivos electrónicos que proporciona la capacidad de computación

ELEMEN

TOS D

E UN

SIGente

Base de datos

Usuarios y operadores del software y del hardware

Colección grande y organizada de información y que es una parte integral del funcionamiento del sistema

ELEMEN

TOS D

E UN

SIDocum

entaciónProcesam

iento:

Manuales, los impresos y otra información descriptiva que explica el uso y/o la operación

Los pasos que definen el uso especifico de cada elemento del sistema

ELEMENTOS DE UN SI

Control: Niveles de control tolerables de rendimiento del sistema

PROCESO DE DESARROLLO DE UN SI

1. Identificación de las alternativas para el desarrollo del sistema.

2. Creación de la propuesta

3. Determinación de las necesidades del ejecutivo


1. Identificación de las alternativas para el desarrollo del sistema:

Identificar si el sistema se lo hace de manera interna y partiendo de cero

Hace modificaciones al existente

Desarrolla el SI partiendo de cero y con la ayuda de desarrollares externos con experiencia


2. Creación de la propuesta:

Claro entendimiento con el ejecutivo

Reducir la resistencia al cambio

Manejar las expectativas, beneficios, informar los riesgos que implica y los recursos que requiere

Lograr el compromiso delos recursos


3. Determinación de las necesidades del ejecutivo:

Cuestionar al ejecutivo acerca de cuales son sus necesidades y requerimientos

Realizar entrevistas con los ejecutivos, directores y gerentes de las diferentes áreas de la empresa

Listar los principales objetivos de la empresa a corto y largo plazo

A partir de la observación o entrevista determinar la información que utiliza en la actualidad el ejecutivo

CARACTERISTICAS DE SI Logran ahorros significativos de mano

de obra Necesitan información de entrada y

salida para generar resultados, operaciones o reportes.

Se adaptan a aplicaciones que se encuentran en el mercado.

Ingeniería de Software

El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo.

Proceso de desarrollo de software

Es aquel en que las necesidades del usuario son traducidas en requerimientos de software.

Proceso de desarrollo de softw

are

Es decir define

› ¿Cuándo de hace?

› ¿Qué se esta haciendo?

› ¿Qué se produjo?

› ¿Quién lo hace?

Curso: fase e interacciones

Actividades: Flujo de trabajo de procesos

Artefactos: Modelos, reportes y documentos

Persona: Grupo de desarrolladores

Ciclo de Vida del Software

Comprende cuatro grandes fases:

› Concepción› Elaboración› Construcción › Transición.


Concepción:

Es definir el alcance del proyecto y definir el caso de uso


Elaboración:

Es proyectar un plan, definir las características y cimentar la arquitectura.


Construcción :Es crear el producto


Transición. :

Transferir el producto al usuario


Modelo en cascada Modelo escala

Análisis

Requisitos

Diseño preliminar y detallado

Implementación & prueba unitaria

Mantenimiento

Integración

Esfuerzo

Tiempo

AnálisisDiseño

Implementación

prueba

Proceso de desarrollo de Software

MAESTRO

RECTOR

Quiero ingresar los datos

de los estudiante

s

Quiero generar reportes

?<HTML> <HEAD> <TITLE> Mi paguina WEB </TITLE> </HEAD> <BODY> <CENTER><h1>Primera Paguina</h1></CENTER> <HR> Esta es mi primera paguina, aunque es muy sencilla. Como el lenguaje HTMLno es dificil <P>aqui va un segundo parrafo <ul> <li><b>el cine</b> <li><i>volly</i> </ul> <ol> <li><pre>salsa</pre> </tt> </ol> <dl> <dt>valores <dd>son actitudes </dl> </BODY> </HTML>

Proceso de desarrollo de software

El problema central del desarrollo de software es transformar las necesidades del cliente en código

“El camino desde las necesidades hasta el código del sistema es tan

complejo que no es posible escribir el código instantáneamente”

Desarrollo de Software Proceso Unificado


Concepción Elaboración Construcción Transición

Objetivos Arquitectura Sistema Corriendo

Presentación del Producto

Para reflexionar¿Qué pasaría, si el ingeniero civil o el

arquitecto construye una casa o un edificio sin hacer sus planos, proyectos o maquetas?

¿Crees que la obra pueda concluirse cubriendo las necesidades, con la calidad necesaria y a tiempo? Simplemente observa a tu alrededor

UMLLenguaje de Modelamiento Unificado


Para representar adecuadamente la arquitectura de un sistema es necesario contar con varios diagramas o vistas. Dada la cantidad de características y de elementos que tiene un sistema de software no es posible incluirlos todos en un solo diagrama y que sirva, además, para todas las personas que participan en el desarrollo. Cada una de estas vistas es una estructura de la arquitectura del sistema, que muestran una parte del sistema como un conjunto de componentes, conectores y restricciones sobre sus tipos y relaciones.


Permite representar la estructura de un sistema a un nivel mayor que el dado por la programación o incluso el diseño

Además, cada estructura puede relacionarse con las demás para complementar la visión integral del sistema.

En UML se utilizan para el modelamiento de un sistema diferentes elementos y relaciones, que tienen una semántica y sintaxis definidas. Estos elementos se agrupan en diagramas preestablecidos que corresponden a diferentes proyecciones del sistema

Notación

Una notación es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (análisis) y los detalles de una arquitectura (diseño) de forma no ambigua.

Notación La acción de dibujar un diagrama no constituye

ni análisis ni diseño

Una notación no es un fin por si misma

El hecho de que una notación sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasiones

La notación son como los planos para un arquitecto o un ingeniero

Notación Una notación no es más que un vehículo para capturar los

razonamientos acerca del comportamiento y la arquitectura de un sistema

Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notación y los lenguajes de programación

El propósito de este tema es describir la sintaxis y semántica de la notación que se utiliza para el análisis y diseño orientado a objetos

Notación - UML UML ofrece nueve diagramas en los cuales modelar sistemas:

1. Diagramas de Casos de Uso para modelar los procesos ’business’.2. Diagramas de Secuencia para modelar el paso de mensajes entre

objetos.3. Diagramas de Colaboración para modelar interacciones entre

objetos.4. Diagramas de Estado para modelar el comportamiento de los

objetos en el sistema.5. Diagramas de Actividad para modelar el comportamiento de los

Casos de Uso, objetos u operaciones.6. Diagramas de Clases para modelar la estructura estática de las

clases en el sistema.7. Diagramas de Objetos para modelar la estructura estática de los

objetos en el sistema.8. Diagramas de Componentes para modelar componentes.9. Diagramas de Implementación para modelar la distribución del

sistema.

Conclusiones ¿Qué es el Proceso Unificado?

¿Cuáles son las fases del proceso unificado?

¿Qué es UML?

¿Qué es Notación?

¿Es importante usar una metodología para desarrollo de SI? Porque

Desarrollo de Software Proceso Unificado


Concepción Elaboración Construcción Transición

Objetivos• Planteamiento del

problema• Determinación de los

Requerimientos.

Arquitectura• Análisis• Diseño

Sistema Corriendo:• Programación• Prueba• Documentación

Presentación del Producto• Implementació

n

Planteamiento del ProblemaConcepción

REGLAS: Identificar los componentes Ubicar el problema dentro de un marco

conceptual Analizar el problema desglosando en

sus unidades más simples Simplificar y eliminar la información

redundante

Determinación de los Requerimientos

HERRAMIENTAS: Datos relevantes Entrevistas Cuestionarios Prototipos

DESARROLLADOR: Comprende que información necesitan

los usuarios para trabajarConcepción


INVOLUCRADOS: Desarrolladores Usuarios Administradores

LOS DESARROLLADORES NECESITAN: Detalles del SI

¿Quién? Personas ¿Qué? Actividades del SI ¿Dónde? Ambiente ¿Cuándo? En que momento ¿Cómo? De que manera se desarrollo

Concepción


AL TÉRMINO DE LA FASE:

Los desarrolladores deben comprender el porque de las funciones del SI

Tener informe sobre personas, objetivos y procedimientos

Concepción

Conclusiones ¿Cuáles son las fases del ciclo de vida dentro del

proceso unificado?

¿Dentro de la Concepción que actividades se realiza?

¿Indica dos reglas para el planteamiento del problema?

¿Qué herramienta utilizarías para determinar los requerimientos del SI?

¿Qué obtiene el desarrollador al finalizar esta etapa?

TAREAElabora una herramienta para determinar los requerimientos

del SI a partir del problema expuesto a continuación:

Se debe realizar un sistema capaz de mantener una base de datos con todos los equipos hardware y software de los laboratorio UNO y TRES del Colegio Eloy Alfaro, de manera que se pueda obtener información acerca del número de licencias instaladas y de los equipos en los que están instaladas dichas licencias.

Además debe ser posible controlar el hardware, las modificaciones efectuadas en los equipos, las averías de dichos equipos, la composición de cada uno de los ordenadores y el software que está instalado en ellos.

Análisis

Aunque el proceso es interactivo los pasos fundamentales son los siguientes:

1. Título de la aplicación El título de una aplicación debe reflejar de la mejor forma

posible sus fines y su funcionalidad:

Ejemplo: Mónica: Su asistente en los negociosTrasgu: Gestión de Hardware y Software

Elaboración

Análisis

2. Documentos de análisis Son la documentación que aporta el cliente que encarga la

aplicación También es la documentación elaborada de forma informal

en reuniones de trabajo para entender las solicitudes del cliente

Documento: Ejemplo de Documento de Análisis

3. Especificación de Requisitos o Requerimientos Es la especificación más técnica y elaborada de los

documentos de análisis Es importante codificar los requisitos para poder seguirlos

a lo largo del proceso de construcción del softwareTarea: Realizar las especificaciones con el documento anterior Elaboración

Diseño Usa la información anterior para hacer el

diseño lógico del SI (pseudo código, DF, etc)

Diseña procedimientos precisos para la captura de datos

Diseño de formas y pantallas Diseña la interfaz del usuario Diseño de base de datos Diseño de control y respaldos

Elaboración

Diseño

4. Diagramas de Casos de Uso: Un caso de uso es una técnica de modelado utilizada para

describir lo que un nuevo sistema debe hacer o lo que un sistema existente ya hace.

Un modelo de casos de uso se construye mediante un proceso iterativo durante las reuniones entre los desarrolladores del sistema y los clientes (y/o los usuarios finales) conduciendo a una especificación de requisitos sobre la que todos coinciden.

Un caso de uso captura algunas de las acciones y comportamientos del sistema y de los actores

Un caso de uso es la típica interacción entre un usuario y un sistema informático Elaboración

Diseño Diagramas de Casos de Uso

Es un diagrama que muestra sistemas, casos de uso y actores

Es una documentación que describe cada caso de uso, cada sistema y cada actor

Es importante codificar cada caso de uso

Los casos de uso sólo muestran aspectos muy generales

Elaboración


Elaboración


El sistema que se desea modelar se representa encerrado en un rectángulo

Los actores son los que interactúan con el sistema. Representan todo lo que necesite intercambiar con el sistema.› Un actor es una clase› Se diferenciará entre actores y usuarios.› Un usuario es una persona que utiliza el sistema› Un actor representa el papel (rol) que una persona desempeña› Un actor es el papel que el usuario juega con respecto al sistema. › Un actor no tiene que ser un humano, puede ser por ejemplo otro

sistema externo que pide información al sistema actual

Por ejemplo una persona puede ser usuario y administrador en un sistema, unas veces actuará como usuario y otras como administrador, pero deben contemplarse ambos actores.

Elaboración


CONCLUSIÓN Los Casos de Uso es un camino específico para utilizar el

sistema

Para cada Caso de Uso, Actor y Sistema se realiza una descripción detallada

Los Casos de Uso tan sólo indican opciones generales

El diagrama de Casos de Uso es un diagrama sencillo que tiene como finalidad dar una visión global de toda la aplicación de forma que se pueda entender de una forma rápida y gráfica tanto por usuarios como por desarrolladores Elaboración


EJEMPLO:

CLIENTE

Elige producto

Pregunta por el precio

Paga el producto

COMPRA PRODUCTO Elaboración

TAREA

Realizar el diagrama de caso de uso de los involucrados en el sistema para los laboratorios.

Proceso de Análisis y Diseño Preliminar

Aunque el proceso es iterativo los pasos fundamentales son los siguientes: 1. Título de la aplicación

El título de una aplicación debe reflejar de la mejor forma posible sus fines y su funcionalidad

2. Documentos de análisis

– Son la documentación que aporta el cliente que encarga la aplicación– También es la documentación elaborada de forma informal en reuniones de trabajo para entender las solicitudes del cliente

3. Especificación de Requisitos o Requerimientos– Es la especificación más técnica y elaborada de los documentos de análisis– Es importante codificar los requisitos para poder seguirlos a lo largo del proceso deconstrucción del software


4. Diagramas de Casos de Uso– Es un diagrama que muestra sistemas, casos de uso y actores– Es una documentación que describe cada caso de uso, cada sistema y cada actor– Es importante codificar cada caso de uso– Los casos de uso sólo muestran aspectos muy generales

5. Escenarios y sub-escenarios– A cada caso de uso le corresponden varios escenarios donde se pueden mostrar los detalles– Cada escenario puede dividirse en sub-escenarios para bajar más el nivel de detalle– Los escenarios se codifican siguiendo los valores de los casos de uso


6. Diagramas de Secuencia– Se corresponden con los escenarios y sub-escenarios pero con mucho más detalle– Siguen la misma codificación que los escenarios y sub-escenarios– Algunos diagramas de secuencia pueden refinarse más en la fase de diseño detallado

7. Diccionario de datos– Contiene todas las clases– Se pueden ir definiendo los miembros de las clases (datos y métodos)– Se iré refinando paso a paso en cada iteración– Las herramientas lo van construyendo automáticamente

Diseño

5. Escenarios y sub-escenarios A cada caso de uso le corresponden varios

escenarios donde se pueden mostrar los detalles

Cada escenario puede dividirse en sub-escenarios para bajar más el nivel de detalle

Los escenarios se codifican siguiendo los valores de los casos de uso

Elaboración

Diseño Escenarios y sub-escenarios

Se enumeran escenarios fundamentales para el funcionamiento del sistema

Se estudia cada escenario utilizando guiones como los que se usan en el cine

Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, así como los mecanismos que relacionan los objetos

De los escenarios iníciales se puede pasar a otros escenarios secundarios

Elaboración


Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas

El estudio de los escenarios con detalle permite ir enriqueciendo el Diccionario de datos

No es necesario hacer todos los escenarios y sub-escenarios posibles si se observa que no enriquecen el diccionario de datos

Elaboración


Numeración:

Titulo:

Precondiciones:

Quien Lo Comienza:

Quien Lo Finaliza:

Postcondiciones:

Descripción:


Numeración: 1.1. Titulo: Hacer pedido Precondiciones: Sugerencias de compra, caducidad de licencias, bajas

permanentehardware, …

Quien Lo Comienza: Responsable de Informática. Quien Lo Finaliza: Responsable de Informática. Postcondiciones: Descripción: Son las operaciones de compra de todos los componentes

(hardware,software y manuales) que realiza el responsable de informática. Además da estosequipos de alta y debe apoyarse en el sistema para gestionar los pedidos correctamente para lo que debe anotar en el sistema que ha pedido un componente a un proveedor ( por tanto que está pendiente de recibir).


Numeración: 1.2. Titulo: Anular pedido Precondiciones: Cambio de precio, cambio de

necesidades de la Empresa. Quien Lo Comienza: Responsable de Informática Quien Lo Finaliza: Responsable de Informática Postcondiciones: Descripción: Esta operación la realiza el responsable de

informática cuando toma la decisión de anular un pedido que había realizado con anterioridad.


Numeración: 1.3 Titulo: Recibir pedido Precondiciones: Haber realizado la petición de

un pedido. Quien Lo Comienza: Responsable de

Informática Quien Lo Finaliza: Responsable de Informática Postcondiciones: Descripción: El responsable de informática

confirma la recepción de los pedidos

Diseño

6. Diagramas de Secuencia Se corresponden con los escenarios y sub-escenarios pero

con mucho más detalle Siguen la misma codificación que los escenarios y sub-

escenarios Algunos diagramas de secuencia pueden refinarse más en

la fase de diseño detallado

7. Diccionario de datos Contiene todas las clases Se pueden ir definiendo los miembros de las clases (datos

y métodos) Se iré refinando paso a paso en cada iteración Las herramientas lo van construyendo automáticamenteElaboración

ingeniería software

Documents