SlideShare una empresa de Scribd logo
INGENIERIA DE SOFTWARE:
Es el conjunto de métodos, técnicas y herramientas que controlan el proceso
integral del desarrollo de software y suministra las bases para construir
software de calidad de forma eficiente en los plazos adecuados.
Los Ingenieros de Software deben:
• Adoptar un enfoque sistemático para llevar a cabo su trabajo.
• Utilizar las herramientas y técnicas apropiadas para resolver el problema
planteado, de acuerdo a las restricciones de desarrollo y a los recursos
disponibles
Docente Articuladora: ISLENY RINCÓN MONSALVE
INGENIERIA DE SOFTWARE Y SU IMPORTANCIA:
 La economía de todos los países desarrollados es dependiente del
software.
 Actualmente cada vez mas sistemas son controlados por software.
 La Ingeniería de Software concierne a teorías, métodos y herramientas
para el desarrollo profesional de software.
 El gasto en la Ingeniería de Software, representa un alto porcentaje del
PIB de los países desarrollados
Docente Articuladora: ISLENY RINCÓN MONSALVE
¿QUÉ ES SOFTWARE?
Programas de cómputo y su documentación asociada: requerimientos,
modelos de diseño y manuales de usuario.
El software puede ser desarrollado para un cliente en particular o para un
mercado general
El software puede ser:
Genérico: desarrollado para venderse a múltiples clientes (Excel, Word, etc.)
A la medida: desarrollado bajo demanda del cliente a un desarrollador
específico.
El software nuevo puede ser creado desarrollando nuevos programas,
configurando sistemas de software genérico o reutilizando software existente
Docente Articuladora: ISLENY RINCÓN MONSALVE
¿QUÉ ES UN PROCESO DE SOFTWARE?
Un conjunto estructurado de actividades cuya meta es el desarrollo o evolución
de un software. Algunas actividades genéricas en todos los procesos de
software son:
 Especificación, qué debe hacer el software y cuáles son sus
especificaciones de desarrollo
 Desarrollo, producción del sistema de software Validación, verificar que el
software cumple con lo solicitado por el cliente
 Evolución, cambiar/adaptar el software a las nuevas demandas
 Estas actividades varían dependiendo de la organización y del tipo de
sistema a desarrollarse
conceptos 1.pdf
Empresas
desarrolladoras
Empresas de
consultoría y
servicio
Empresas de
hardware y
comercialización
Empresas de
internet y Datos
El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el
software tiene unas características considerablemente distintas a las del hardware:
•El software se desarrolla, no se fabrica en un sentido clásico. Se adquiere mediante
un buen diseños.
•El software no se estropea. El software no es susceptible a los males del entorno que
hacen que el hardware se estropee. Cada fallo en el software indica un error en el diseño
o en el proceso mediante el que se tradujo el diseño a código maquina ejecutable. Por
tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que
la del mantenimiento del hardware.
•La mayoría del software se construye a medida, en vez de ensamblar componentes
existentes. No existen catálogos de componentes de software. Se puede comprar
software ya desarrollado, pero solo como una unidad completa, no como componentes
que pueden reensamblarse en nuevos programas.
conceptos 1.pdf
• Todo el mundo exige que se realicen cambios sobre el Software
como respuesta a pequeños cambios del entorno.
• Además no es fácil comprender su comportamiento, según
Pressman:
– La curva de fallos del Hardware.
– La curva ideal de fallos del Software.
– La curva real de fallos del Software.
Tiempo
Indice
de
fallos
Defectos fabricación Estropeado
Obsolescencia
Indice
de
fallos
Defectos fabricación
Mismo nivel hasta obsoleto
Obsolescencia
Tiempo
Tiempo
Indice
de
fallos
Defectos fabricación
Curva ideal
Cambio Cambio Cambio
Obsolescencia
1. Planificación y/o Levantamiento de requerimientos
Productos que se obtienen de esta etapa:
• Requerimientos del sistema
• Especificaciones generales del sistema
• Costo y tiempos de ejecución del proyecto
• Recursos requeridos para el sistema
• Factibilidad del sistema
2. Análisis y diseño
Análisis y diseño
Productos generales que se obtienen de esta etapa:
• Modelos de casos de uso (reglas del negocio)
• Interfaces de entrada y salida del sistema
• Modelo relacional de la base de datos
http://www.escribimos.com.ar/www/soft.htm
MODELO LINEAL SECUENCIAL
MODELO V
MODELO SASHIMI
EL MODELO DRA (DESARROLLO RÁPIDO DE APLICACIONES)
EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS
MODELO EVOLUTIVO
EL MODELO INCREMENTAL
MODELO ITERATIVO
EL MODELO ESPIRAL
• “Sistema es un conjunto de cosas que ordenadamente relacionadas entre sí
contribuyen a un determinado objetivo.” (Real Academia Española)
• “Un modelo formado por una serie de elementos interrelacionados entre sí, que
opera en un entorno cambiante y con unos determinados objetivos”.
• Elementos de un sistema:
Los componentes del sistema.
Las relaciones entre ellos, que
determinan la estructura del
sistema.
El objetivo del sistema.
El entorno del sistema: aquello que lo
rodea, dentro del cual está ubicado.
Los límites del sistema: la frontera entre
lo que es el sistema y lo que constituye el
entorno.
conceptos 1.pdf
Papel fundamental de los
“condición que necesita el usuario para resolver un problema o conseguir un objetivo
determinado”. Los requisitos de un sistema son los aspectos que el sistema desarrollado
debe cumplir. Surgen de las necesidades del cliente, de las limitaciones del entorno donde se
va a implantar o de la propia gestión de la información que debe realizar el sistema. Los
requisitos sirven para acotar la funcionalidad o la construcción del sistema suponiendo límites
al diseño del sistema y enumerando todas las funcionalidades que debe cubrir el sistema.
Los requisitos van a delimitar cómo quiere el cliente que se comporte el sistema, que información
tiene que manejar y cómo la debe procesar y presentar. Para identificar todos estos aspectos se
deben estudiar y analizar los requerimientos funcionales y no funcionales:
Afectan directamente a la funcionalidad principal del sistema. Normalmente esta
funcionalidad describe los procesos de negocio a los que se destina el sistema.
1.1 Requisitos de Actores
Son los que afectan a los diferentes actores del sistema, que van a proporcionarle la
información de entrada y van a recibir la información de salida del sistema. En este
apartado recogeremos requisitos por ejemplo de :
·..
·),..
Usuarios Son los responsables de interactuar con el sistema
Grupos
Permite realizar conjuntos de usuarios con características
comunes, para simplificar las reglas de interacción entre los
usuarios y el sistema
Perfiles
Permite agrupar todas las características que distinguen a un
usuario o grupo
Papeles (roles)
Permite asignar grupos de funcionalidades a los usuarios y grupos,
permitiendo diferenciar el comportamiento de los usuarios con el
sistema según la actividad o proceso a realizar en el mismo
1.2 Requisitos de Interfaz
Refleja todos los requisitos que definen la forma de enviar la información a procesar por los
usuarios al sistema, y la forma de recibir la respuesta del sistema por el usuario. Entre ellos
podemos distinguir:
Medios de
interacción
Aplicación de escritorio, páginas Web,
Pantallas formularios y demás elementos de la interfaz de usuario
Mensajes
intercambios y protocolos de comunicación, fundamentales para
describir las interacciones entre sistemas
CLAMB
Pantallas de gestión normalizadas: consultas, listados, altas,
modificaciones y bajas.
Informes documentos, archivos y datos en general generados por el sistema.
1.3 Requisitos de Procesamiento
Son aquellos requisitos que indican qué hacer con los datos de entrada, cómo procesarlos y
generar datos de salida. Indican los requisitos que hay que aplicar a las funciones y procesos
internos. Hay que definir qué datos hay que tratar y mediante qué procesos se van a tratar.
Normalmente para una aplicación de gestión se recogen los requisitos que definen la lógica de
negocio.
1.4 Requisitos de Persistencia
En este se recogen los requisitos que afectan a la información que se debe persistir en el sistema,
es decir la información que se debe guardar entre diferentes ejecuciones del sistema.
Normalmente tendremos los requisitos que nos permitirán construir el modelo de datos del
sistema.
1.5 Requisitos de Gestión y Administración
Estos requisitos recogen todas las funciones que son necesarias para gestionar s el sistema, por
ejemplo la gestión de usuarios, gestión de la configuración del sistema y otras funciones del
sistema que se apartan de la función principal del sistema.
se recogen todos los requisitos del sistema que no representan la funcionalidad principal del
sistema, sino que fijan condiciones para realizar dicha funcionalidad.
2.1 Requisitos de Disponibilidad
Definen la disponibilidad del sistema, el tiempo que debe estar operativo, así como el
comportamiento del sistema en caso de fallos. Entre ellas podemos enumerar:
§ Tiempo total de disponibilidad
§ Tiempo medio entre fallos
§ Tolerancia a fallos en el sistema o en su acceso
§ Tolerancia a fallos de su base de datos, si la tiene
§ Tolerancia a fallos de otros sistemas o comunicación con sistemas externos
§ Operativas que deben estar disponibles en caso de fallos de alguna de las partes del
sistema
2.2 Requisitos de Rendimiento
Se tiene en cuenta las métricas de rendimiento, pues suelen ser fácilmente medibles. Entre
ellos podemos sugerir los siguientes:
§ Velocidad de las peticiones al sistema (número de peticiones que debe responder en cierto
tiempo)
§ Tiempo medio de respuesta por tipo de petición, que sería el tiempo máximo (en media) que
debería tardar el sistema en contestar a una petición
§ Velocidad en la comunicación con el sistema
§ Velocidad en la gestión de la interfaz del usuario
2.3 Requisitos de Calidad
Aquí recogemos los requisitos que afectan a la gestión de la Calidad en el desarrollo del
proyecto. Entre ellos podemos destacar:
§ Normativas y procedimientos de gestión del proyecto
§ Normativas y procedimientos de desarrollo
§ Normativas y procedimientos de documentación
§ Normativas y Procedimientos de generación de entregables
§ Normativas de calidad del Cliente
§ Pruebas de Certificación de Calidad que deben superar los entregables.
2.4 Requisitos de Almacenamiento
Aquí se recogen todos los requisitos que especifican el cómo, dónde y cuándo guardar los
datos persistentes del sistema, así como la capacidad del sistema de almacenamiento de los
mismos, su seguridad, su fiabilidad, su protección contra fallos o intento de acceso no
autorizado y su política de respaldo.
2.5 Requisitos de Seguridad
Aquí se recogen todos los requisitos relativos a la seguridad del sistema, como pueden ser:
§ Control de acceso al sistema y autenticación de usuarios
§ Políticas de usuarios y contraseñas, si las hubiere.
§ Desactivación de usuarios.
§ Control y auditoría de las acciones de los usuarios
§ Políticas de gestión de la seguridad y de los elementos y funcionalidades del sistema.
§ Métodos de agrupación de usuarios, y de permisos. Esquemas de administración y
almacenamiento de la seguridad
§ Gestión de los roles de los usuarios, si hubiese.
§ Medidas de protección del sistema frente a ataques externos
§ Normativas y protocolos de seguridad que debe cumplir el sistema
§ Auditorías de seguridad y alarmas.
2.6 Requisitos de Escalabilidad
Aquí se recogen los requisitos de capacidad del sistema y cómo se debe poder ampliar si es
necesario. Si el sistema es utilizado por múltiples usuarios simultáneos, debe disponer de un
plan para redimensionar el sistema al crecer el número de usuarios.
2.7 Requisitos Legales y Normativas
En este apartado se recogen los requisitos legales que debe cumplir el sistema, es decir, toda
la normativa legal que aplica al sistema, las restricciones legales de su uso y las normativas de
gestión de la información confidencial. También se incluyen los requisitos de destrucción de
información confidencial al final del ciclo de vida de la misma
Recogen todos los requisitos que debe cumplir el sistema, independientemente de la
funcionalidad que debe cubrir.
3.1 Requisitos de Arquitectura
Estos requisitos definen arquitectura y componentes del sistema, cuando es un sistema creado
a partir de varios, modúlalos.
3.2 Requisitos de Software
Se recogen todos los requisitos de software que se aplicarán al sistema, como pueden ser:
• Sistemas operativos de los diferentes módulos que forman el sistema, incluyendo versiones
y actualizaciones.
• Software adicional necesario en el sistema
• Requisitos de actualización del software de base del sistema
3.3 Requisitos de Hardware
Se recogen los requisitos de hardware de los componentes del sistema. Entre ellos; tipos de
servidores, configuración de los mismos, tipos de unidades de disco y configuración, sistemas de
backup, etc.
3.4 Requisitos de Comunicaciones
Aquí se recogen los requisitos para interconectar el sistema se definen los parámetros de red
requeridos, topología, tipos de enlace, anchos de banda, etc.
3.5 Requisitos de Integración
Se recogen los requisitos de integración del sistema con otros sistemas externos o del cliente. Se
debe incluir los protocolos que se deben soportar, los servicios que nos proporcionan o que
debemos proporcionar, las aplicaciones con las que debemos interactuar, etc.
3.6 Requisitos de Contingencia
Aquí enunciaremos los requisitos que debe cumplir nuestro sistema en caso de contingencia, y
que servirán de base para desarrollar el plan de contingencia del sistema.
Incertidumbre: Puede o no ocurrir, no hay
riesgos del 100% de probabilidad.
Pérdida: Si el riesgo ocurre, hay pérdidas.
Categorías
de riesgos
de software
1. Riesgos del proyecto:
2. Riesgos del producto:
3. Riesgos del negocio:
Amenazan al plan del proyecto; la planificación
temporal y los costos. Ej: Pérdida de un diseñador
experimentado.
Amenazan la calidad y la planificación temporal
del SW; la implementación puede llegar a ser difícil o
imposible. Ej: Rendimiento de un componente menor al
esperado.
Amenazan la viabilidad del software a construir.
Ej: Un competidor introduzca un nuevo producto.

Más contenido relacionado

PPTX
Tarea 3 fundamentos del computador
PPT
Requerimientos
PPT
Requisitos
PPTX
Fundamento del computador tarea 2
PPTX
PPTX
Software sao
PPTX
Software
DOCX
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Tarea 3 fundamentos del computador
Requerimientos
Requisitos
Fundamento del computador tarea 2
Software sao
Software
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...

Similar a conceptos 1.pdf (20)

PPTX
IngenieriaDeRequisitos2.pptx
PPTX
Guide to the software engineering body of knowledge
PPT
Analisis y Diseño de Sistemas
PPTX
Tarea 2 de fundamentos del computador
PPTX
Requisitos
PPTX
Software
DOCX
Tema 3 unidad v - scm
PPTX
Proceso de desarrollo del software
PDF
Analisis de requerimientos, Ingenieria de Software
PPTX
Requerimientos del software
DOCX
Análisis de requerimientos
PPTX
Presentación digital Eliezer Alas
PPTX
Trabajo 2 exposicion
PPTX
Requerimientos del Software
PPTX
Requerimientos del Software
DOCX
Requerimiento
PPTX
Ingenieria de requerimientos
PPT
Unidad 1.3 Analisis De Requerimientos
DOCX
Clasificación de los requerimientos
PPTX
Tipos de software
IngenieriaDeRequisitos2.pptx
Guide to the software engineering body of knowledge
Analisis y Diseño de Sistemas
Tarea 2 de fundamentos del computador
Requisitos
Software
Tema 3 unidad v - scm
Proceso de desarrollo del software
Analisis de requerimientos, Ingenieria de Software
Requerimientos del software
Análisis de requerimientos
Presentación digital Eliezer Alas
Trabajo 2 exposicion
Requerimientos del Software
Requerimientos del Software
Requerimiento
Ingenieria de requerimientos
Unidad 1.3 Analisis De Requerimientos
Clasificación de los requerimientos
Tipos de software
Publicidad

Más de CESARAS4 (17)

PPT
Lenguaje de Manipulacion de datos sql.ppt
PPT
LENGUAJE DE MANIPULACION DE DATOS (DML)
PPTX
CERTIFICATES by Savanna Cunningham.pptx
PDF
ANEXO 06 Orden de PRELACION del 2024.pdf
PPSX
validacion de datos de dtos 3214564.ppsx
PPTX
Clases de html y coss para diseño de paginas web
PPT
1817054.ppt
PPT
dokumen.tips_relacionar-tablas-en-sql.ppt
PPT
5640999.ppt
PPT
12341467.ppt
PDF
clasificaciondemetodologiasparaeldesarrollodesoftware-151202020341-lva1-app68...
PDF
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
PPT
SEGURIDAA.ppt
PPT
14073596.ppt
DOCX
6_Formato Informe mensual.docx
DOC
INGL+ëS - 2-¦ A+æO 2017 (2)(1).doc
DOC
INGL+ëS - 1-¦ A+æO 2017 (2)(1).doc
Lenguaje de Manipulacion de datos sql.ppt
LENGUAJE DE MANIPULACION DE DATOS (DML)
CERTIFICATES by Savanna Cunningham.pptx
ANEXO 06 Orden de PRELACION del 2024.pdf
validacion de datos de dtos 3214564.ppsx
Clases de html y coss para diseño de paginas web
1817054.ppt
dokumen.tips_relacionar-tablas-en-sql.ppt
5640999.ppt
12341467.ppt
clasificaciondemetodologiasparaeldesarrollodesoftware-151202020341-lva1-app68...
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
SEGURIDAA.ppt
14073596.ppt
6_Formato Informe mensual.docx
INGL+ëS - 2-¦ A+æO 2017 (2)(1).doc
INGL+ëS - 1-¦ A+æO 2017 (2)(1).doc
Publicidad

Último (20)

PDF
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
DOCX
Informe_practica pre Final.docxddadssasdddddddddddddddddddddddddddddddddddddddd
PDF
Habitos de Ricos - Juan Diego Gomez Ccesa007.pdf
PDF
Guia de Tesis y Proyectos de Investigacion FS4 Ccesa007.pdf
DOCX
PLAN DE AREA DE CIENCIAS SOCIALES TODOS LOS GRUPOS
PDF
Escuelas Desarmando una mirada subjetiva a la educación
PDF
Unidad de Aprendizaje 5 de Educacion para el Trabajo EPT Ccesa007.pdf
PDF
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
PPTX
Welcome to the 8th Physical Science Class 2025-2026
PDF
ACERTIJO Súper Círculo y la clave contra el Malvado Señor de las Formas. Por ...
DOCX
PLAN DE CASTELLANO 2021 actualizado a la normativa
PDF
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
PDF
Teologia-Sistematica-Por-Lewis-Sperry-Chafer_060044.pdf
PDF
Fundamentos_Educacion_a_Distancia_ABC.pdf
PDF
Unidad de Aprendizaje 5 de Matematica 1ro Secundaria Ccesa007.pdf
PDF
Metodologías Activas con herramientas IAG
DOCX
V UNIDAD - SEGUNDO GRADO. del mes de agosto
PDF
ciencias-1.pdf libro cuarto basico niños
PDF
Atencion prenatal. Ginecologia y obsetricia
PPTX
Presentación de la Cetoacidosis diabetica.pptx
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
Informe_practica pre Final.docxddadssasdddddddddddddddddddddddddddddddddddddddd
Habitos de Ricos - Juan Diego Gomez Ccesa007.pdf
Guia de Tesis y Proyectos de Investigacion FS4 Ccesa007.pdf
PLAN DE AREA DE CIENCIAS SOCIALES TODOS LOS GRUPOS
Escuelas Desarmando una mirada subjetiva a la educación
Unidad de Aprendizaje 5 de Educacion para el Trabajo EPT Ccesa007.pdf
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
Welcome to the 8th Physical Science Class 2025-2026
ACERTIJO Súper Círculo y la clave contra el Malvado Señor de las Formas. Por ...
PLAN DE CASTELLANO 2021 actualizado a la normativa
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
Teologia-Sistematica-Por-Lewis-Sperry-Chafer_060044.pdf
Fundamentos_Educacion_a_Distancia_ABC.pdf
Unidad de Aprendizaje 5 de Matematica 1ro Secundaria Ccesa007.pdf
Metodologías Activas con herramientas IAG
V UNIDAD - SEGUNDO GRADO. del mes de agosto
ciencias-1.pdf libro cuarto basico niños
Atencion prenatal. Ginecologia y obsetricia
Presentación de la Cetoacidosis diabetica.pptx

conceptos 1.pdf

  • 1. INGENIERIA DE SOFTWARE: Es el conjunto de métodos, técnicas y herramientas que controlan el proceso integral del desarrollo de software y suministra las bases para construir software de calidad de forma eficiente en los plazos adecuados. Los Ingenieros de Software deben: • Adoptar un enfoque sistemático para llevar a cabo su trabajo. • Utilizar las herramientas y técnicas apropiadas para resolver el problema planteado, de acuerdo a las restricciones de desarrollo y a los recursos disponibles Docente Articuladora: ISLENY RINCÓN MONSALVE
  • 2. INGENIERIA DE SOFTWARE Y SU IMPORTANCIA:  La economía de todos los países desarrollados es dependiente del software.  Actualmente cada vez mas sistemas son controlados por software.  La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de software.  El gasto en la Ingeniería de Software, representa un alto porcentaje del PIB de los países desarrollados Docente Articuladora: ISLENY RINCÓN MONSALVE
  • 3. ¿QUÉ ES SOFTWARE? Programas de cómputo y su documentación asociada: requerimientos, modelos de diseño y manuales de usuario. El software puede ser desarrollado para un cliente en particular o para un mercado general El software puede ser: Genérico: desarrollado para venderse a múltiples clientes (Excel, Word, etc.) A la medida: desarrollado bajo demanda del cliente a un desarrollador específico. El software nuevo puede ser creado desarrollando nuevos programas, configurando sistemas de software genérico o reutilizando software existente Docente Articuladora: ISLENY RINCÓN MONSALVE
  • 4. ¿QUÉ ES UN PROCESO DE SOFTWARE? Un conjunto estructurado de actividades cuya meta es el desarrollo o evolución de un software. Algunas actividades genéricas en todos los procesos de software son:  Especificación, qué debe hacer el software y cuáles son sus especificaciones de desarrollo  Desarrollo, producción del sistema de software Validación, verificar que el software cumple con lo solicitado por el cliente  Evolución, cambiar/adaptar el software a las nuevas demandas  Estas actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse
  • 6. Empresas desarrolladoras Empresas de consultoría y servicio Empresas de hardware y comercialización Empresas de internet y Datos
  • 7. El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el software tiene unas características considerablemente distintas a las del hardware: •El software se desarrolla, no se fabrica en un sentido clásico. Se adquiere mediante un buen diseños. •El software no se estropea. El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Cada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradujo el diseño a código maquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware. •La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. No existen catálogos de componentes de software. Se puede comprar software ya desarrollado, pero solo como una unidad completa, no como componentes que pueden reensamblarse en nuevos programas.
  • 9. • Todo el mundo exige que se realicen cambios sobre el Software como respuesta a pequeños cambios del entorno. • Además no es fácil comprender su comportamiento, según Pressman: – La curva de fallos del Hardware. – La curva ideal de fallos del Software. – La curva real de fallos del Software.
  • 11. Indice de fallos Defectos fabricación Mismo nivel hasta obsoleto Obsolescencia Tiempo
  • 13. 1. Planificación y/o Levantamiento de requerimientos Productos que se obtienen de esta etapa: • Requerimientos del sistema • Especificaciones generales del sistema • Costo y tiempos de ejecución del proyecto • Recursos requeridos para el sistema • Factibilidad del sistema 2. Análisis y diseño Análisis y diseño Productos generales que se obtienen de esta etapa: • Modelos de casos de uso (reglas del negocio) • Interfaces de entrada y salida del sistema • Modelo relacional de la base de datos
  • 15. MODELO LINEAL SECUENCIAL MODELO V MODELO SASHIMI EL MODELO DRA (DESARROLLO RÁPIDO DE APLICACIONES) EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS MODELO EVOLUTIVO EL MODELO INCREMENTAL MODELO ITERATIVO EL MODELO ESPIRAL
  • 16. • “Sistema es un conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a un determinado objetivo.” (Real Academia Española) • “Un modelo formado por una serie de elementos interrelacionados entre sí, que opera en un entorno cambiante y con unos determinados objetivos”. • Elementos de un sistema: Los componentes del sistema. Las relaciones entre ellos, que determinan la estructura del sistema. El objetivo del sistema. El entorno del sistema: aquello que lo rodea, dentro del cual está ubicado. Los límites del sistema: la frontera entre lo que es el sistema y lo que constituye el entorno.
  • 19. “condición que necesita el usuario para resolver un problema o conseguir un objetivo determinado”. Los requisitos de un sistema son los aspectos que el sistema desarrollado debe cumplir. Surgen de las necesidades del cliente, de las limitaciones del entorno donde se va a implantar o de la propia gestión de la información que debe realizar el sistema. Los requisitos sirven para acotar la funcionalidad o la construcción del sistema suponiendo límites al diseño del sistema y enumerando todas las funcionalidades que debe cubrir el sistema.
  • 20. Los requisitos van a delimitar cómo quiere el cliente que se comporte el sistema, que información tiene que manejar y cómo la debe procesar y presentar. Para identificar todos estos aspectos se deben estudiar y analizar los requerimientos funcionales y no funcionales:
  • 21. Afectan directamente a la funcionalidad principal del sistema. Normalmente esta funcionalidad describe los procesos de negocio a los que se destina el sistema. 1.1 Requisitos de Actores Son los que afectan a los diferentes actores del sistema, que van a proporcionarle la información de entrada y van a recibir la información de salida del sistema. En este apartado recogeremos requisitos por ejemplo de : ·.. ·),.. Usuarios Son los responsables de interactuar con el sistema Grupos Permite realizar conjuntos de usuarios con características comunes, para simplificar las reglas de interacción entre los usuarios y el sistema Perfiles Permite agrupar todas las características que distinguen a un usuario o grupo Papeles (roles) Permite asignar grupos de funcionalidades a los usuarios y grupos, permitiendo diferenciar el comportamiento de los usuarios con el sistema según la actividad o proceso a realizar en el mismo
  • 22. 1.2 Requisitos de Interfaz Refleja todos los requisitos que definen la forma de enviar la información a procesar por los usuarios al sistema, y la forma de recibir la respuesta del sistema por el usuario. Entre ellos podemos distinguir: Medios de interacción Aplicación de escritorio, páginas Web, Pantallas formularios y demás elementos de la interfaz de usuario Mensajes intercambios y protocolos de comunicación, fundamentales para describir las interacciones entre sistemas CLAMB Pantallas de gestión normalizadas: consultas, listados, altas, modificaciones y bajas. Informes documentos, archivos y datos en general generados por el sistema.
  • 23. 1.3 Requisitos de Procesamiento Son aquellos requisitos que indican qué hacer con los datos de entrada, cómo procesarlos y generar datos de salida. Indican los requisitos que hay que aplicar a las funciones y procesos internos. Hay que definir qué datos hay que tratar y mediante qué procesos se van a tratar. Normalmente para una aplicación de gestión se recogen los requisitos que definen la lógica de negocio. 1.4 Requisitos de Persistencia En este se recogen los requisitos que afectan a la información que se debe persistir en el sistema, es decir la información que se debe guardar entre diferentes ejecuciones del sistema. Normalmente tendremos los requisitos que nos permitirán construir el modelo de datos del sistema. 1.5 Requisitos de Gestión y Administración Estos requisitos recogen todas las funciones que son necesarias para gestionar s el sistema, por ejemplo la gestión de usuarios, gestión de la configuración del sistema y otras funciones del sistema que se apartan de la función principal del sistema.
  • 24. se recogen todos los requisitos del sistema que no representan la funcionalidad principal del sistema, sino que fijan condiciones para realizar dicha funcionalidad. 2.1 Requisitos de Disponibilidad Definen la disponibilidad del sistema, el tiempo que debe estar operativo, así como el comportamiento del sistema en caso de fallos. Entre ellas podemos enumerar: § Tiempo total de disponibilidad § Tiempo medio entre fallos § Tolerancia a fallos en el sistema o en su acceso § Tolerancia a fallos de su base de datos, si la tiene § Tolerancia a fallos de otros sistemas o comunicación con sistemas externos § Operativas que deben estar disponibles en caso de fallos de alguna de las partes del sistema
  • 25. 2.2 Requisitos de Rendimiento Se tiene en cuenta las métricas de rendimiento, pues suelen ser fácilmente medibles. Entre ellos podemos sugerir los siguientes: § Velocidad de las peticiones al sistema (número de peticiones que debe responder en cierto tiempo) § Tiempo medio de respuesta por tipo de petición, que sería el tiempo máximo (en media) que debería tardar el sistema en contestar a una petición § Velocidad en la comunicación con el sistema § Velocidad en la gestión de la interfaz del usuario
  • 26. 2.3 Requisitos de Calidad Aquí recogemos los requisitos que afectan a la gestión de la Calidad en el desarrollo del proyecto. Entre ellos podemos destacar: § Normativas y procedimientos de gestión del proyecto § Normativas y procedimientos de desarrollo § Normativas y procedimientos de documentación § Normativas y Procedimientos de generación de entregables § Normativas de calidad del Cliente § Pruebas de Certificación de Calidad que deben superar los entregables. 2.4 Requisitos de Almacenamiento Aquí se recogen todos los requisitos que especifican el cómo, dónde y cuándo guardar los datos persistentes del sistema, así como la capacidad del sistema de almacenamiento de los mismos, su seguridad, su fiabilidad, su protección contra fallos o intento de acceso no autorizado y su política de respaldo.
  • 27. 2.5 Requisitos de Seguridad Aquí se recogen todos los requisitos relativos a la seguridad del sistema, como pueden ser: § Control de acceso al sistema y autenticación de usuarios § Políticas de usuarios y contraseñas, si las hubiere. § Desactivación de usuarios. § Control y auditoría de las acciones de los usuarios § Políticas de gestión de la seguridad y de los elementos y funcionalidades del sistema. § Métodos de agrupación de usuarios, y de permisos. Esquemas de administración y almacenamiento de la seguridad § Gestión de los roles de los usuarios, si hubiese. § Medidas de protección del sistema frente a ataques externos § Normativas y protocolos de seguridad que debe cumplir el sistema § Auditorías de seguridad y alarmas.
  • 28. 2.6 Requisitos de Escalabilidad Aquí se recogen los requisitos de capacidad del sistema y cómo se debe poder ampliar si es necesario. Si el sistema es utilizado por múltiples usuarios simultáneos, debe disponer de un plan para redimensionar el sistema al crecer el número de usuarios. 2.7 Requisitos Legales y Normativas En este apartado se recogen los requisitos legales que debe cumplir el sistema, es decir, toda la normativa legal que aplica al sistema, las restricciones legales de su uso y las normativas de gestión de la información confidencial. También se incluyen los requisitos de destrucción de información confidencial al final del ciclo de vida de la misma
  • 29. Recogen todos los requisitos que debe cumplir el sistema, independientemente de la funcionalidad que debe cubrir. 3.1 Requisitos de Arquitectura Estos requisitos definen arquitectura y componentes del sistema, cuando es un sistema creado a partir de varios, modúlalos. 3.2 Requisitos de Software Se recogen todos los requisitos de software que se aplicarán al sistema, como pueden ser: • Sistemas operativos de los diferentes módulos que forman el sistema, incluyendo versiones y actualizaciones. • Software adicional necesario en el sistema • Requisitos de actualización del software de base del sistema
  • 30. 3.3 Requisitos de Hardware Se recogen los requisitos de hardware de los componentes del sistema. Entre ellos; tipos de servidores, configuración de los mismos, tipos de unidades de disco y configuración, sistemas de backup, etc. 3.4 Requisitos de Comunicaciones Aquí se recogen los requisitos para interconectar el sistema se definen los parámetros de red requeridos, topología, tipos de enlace, anchos de banda, etc. 3.5 Requisitos de Integración Se recogen los requisitos de integración del sistema con otros sistemas externos o del cliente. Se debe incluir los protocolos que se deben soportar, los servicios que nos proporcionan o que debemos proporcionar, las aplicaciones con las que debemos interactuar, etc.
  • 31. 3.6 Requisitos de Contingencia Aquí enunciaremos los requisitos que debe cumplir nuestro sistema en caso de contingencia, y que servirán de base para desarrollar el plan de contingencia del sistema.
  • 32. Incertidumbre: Puede o no ocurrir, no hay riesgos del 100% de probabilidad. Pérdida: Si el riesgo ocurre, hay pérdidas.
  • 33. Categorías de riesgos de software 1. Riesgos del proyecto: 2. Riesgos del producto: 3. Riesgos del negocio: Amenazan al plan del proyecto; la planificación temporal y los costos. Ej: Pérdida de un diseñador experimentado. Amenazan la calidad y la planificación temporal del SW; la implementación puede llegar a ser difícil o imposible. Ej: Rendimiento de un componente menor al esperado. Amenazan la viabilidad del software a construir. Ej: Un competidor introduzca un nuevo producto.