El Ciclo de Vida del Software propone algunos modelos para explicar las fases o etapas que cumple el producto de software desde los requerimientos inicial hasta su nueva entrega.
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
Instituto Universitario Politécnico "Santiago Mariño"
Ingeniería de Sistemas
Sede Barcelona
Prof.: Aquiles Torrealba
Alumno: Rafael Brito C.I.: 25.286.285
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
Instituto Universitario Politécnico "Santiago Mariño"
Ingeniería de Sistemas
Sede Barcelona
Prof.: Aquiles Torrealba
Alumno: Rafael Brito C.I.: 25.286.285
En muchos casos esta metodología se considera como un método independiente, este método pertenece a los modelos de desarrollo evolutivo.
Prototipo es una representación o modelo del sistema a desarrollar que, a diferencia de un modelo de simulación, incorpora componentes del producto real, este será una representación del sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas.
Un prototipo tiene un funcionamiento limitado en cuanta a capacidades, confiabilidad o eficiencia.
En la utilización de este método se inicia con la definición de los objetivos globales para el software para luego pasar a identificar los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado
Este modelo nos permite entender el contexto del sistema, además de capturar los requerimientos funcionales y no funcionales de la empresa para el desarrollo del sistema.
Técnicas e instrumentos para la recopilación de informaciónWilfredo Mogollón
Las técnicas e Instrumentos para recopilar información son herramientas muy importantes en la captura y entendimiento de los requerimientos para el desarrollo de software.
Extreme Programming es una metodología ágil de desarrollo que propone un plan de desarrollo de software de corto plazo permitiendo una mayor interacción con el usuario.
Ingeniería de software y el paradigma orientado a objetosWilfredo Mogollón
Todo proyecto de ingeniería nace de un problema y la ingeniería de software no es excepción. Estable principios básicos para el desarrollo de software confiable que cubra las necesidades de la empresa.
Una metodología de Desarrollo es como una receta de cocina, hay se visualizan los requerimientos, las herramientas y técnicas a utilizar para crear el platillo (software). De su buen eso depende el éxito del proyecto.
La información la componen datos que se han colocado en un contexto significativo y útil y se ha comunicado a un receptor, quien la utiliza para tomar decisiones.
El análisis de sistemas orientado a objetos es un enfoque de la ingeniería de software que plantea una nueva forma de pensar para entender el problema basado en modelos funcionales compuestos por verbos y sustantivos.
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
En esta charla, nos sumergiremos en los desafíos emergentes que la inteligencia artificial (IA) y los Large Language Models (LLMs) traen al mundo de la calidad del software y el testing. Exploraremos cómo la integración, uso o diseño de modelos de IA plantean nuevos retos, incluyendo la calidad de datos y detección de sesgos, sumando la complejidad de probar algo no determinístico. Revisaremos algunas propuestas que se están llevando adelante para ajustar nuestras tareas de testing al desarrollo de este tipo de sistemas, incluyendo enfoques de pruebas automatizadas y observabilidad.
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
2. “Una aproximación lógica a la adquisición, el
suministro, el desarrollo, la explotación y el
mantenimiento del software”
IEEE 1074
“Un marco de referencia que contiene los
procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software,
abarcando la vida del sistema desde la definición
de los requisitos hasta la finalización de su uso”
ISO 12207-1
3.
4. FABREGAS:
1- Requerimientos
2- Análisis/Diseño
3- Construcción
4- Pruebas
5- Producción/Mantenimiento
SENN:
1- Investigación Preliminar
2- Determ. de Requerimientos.
3- Diseño del Sistema
4- Desarrollo del Software
5- Prueba del Sistema
6- Implantación y Evaluación
PRESSMAN:
1- Análisis
2- Diseño
3- Codificación
4- Prueba
5- Mantenimiento
EN GENERAL USAREMOS:
1- Análisis
2- Diseño
3- Implementación
4- Mantenimiento
5.
6. • Implantación Ascendente
• Las fases deben sucederse de manera Secuencial
• El usuario no ve resultados, sino hasta el final
• El usuario o el ambiente pueden cambiar las
especificaciones originales del sistema.
• Presenta numerosos problemas Analista-Usuario
• Manejable como proyecto
16. Sistemas II.
1. ANALISIS:
1.1. Estudio Preliminar
1.2. Levantamiento de Información
1.3. Definición del Problema
1.4. Elaboración del Modelo Funcional del Sistema actual
1.5. Determinación de Requerimientos
1.6. Descripción y Evaluación de Alternativas
1.7. Aprobación de alternativas
17. Sistemas II.
2.DISEÑO
2.1. Elaborar Modelo Funcional del Sistema Propuesto
2.2. Diseño Lógico
2.3. Elaboración y Presentación del prototipo del Sistema
2.4. Aprobación del Sistema Propuesto
18. Sistemas II.
3. IMPLEMENTACION
3.1. Desarrollo del Software
3.2. Prueba del Sistema
3.3. Puesta en Marcha
¿ Qué significa poner en
Marcha un Sistema ?
19. Sistemas II.
PUESTA EN MARCHA:
Actividad de traslado de una aplicación probada a un ambiente de producción
- Acondicionamiento de locales
- Organización del Cliente
- Entregar aplicación probada
- Elaborar datos en Vivo
- Adiestramiento
- Carga de datos en vivo
- Entrega de documentación
- Asignar Responsabilidades
- Determinar FIN de la instalación
20.
21. Este, aunque es más comúnmente conocido como
modelo en cascada es también llamado «modelo
clásico», «modelo tradicional» o «modelo lineal
secuencial».
22. CRITICAS
No refleja realmente el proceso de desarrollo
del software
Se tarda mucho tiempo en pasar por todo el
ciclo
Perpetua el fracaso de la industria del software
en su comunicación con el usuario final
El mantenimiento se realiza en el código fuente
Las revisiones de proyectos de gran
complejidad son muy difíciles
Impone una estructura de gestión de proyectos
23. Los procesos iterativos pueden ayudar a desvelar
metas del diseño en el caso de clientes que no saben
cómo definir lo que quieren.
24. Observaciones:
Se evitan proyectos largos y se entrega “Algo de
valor” a los usuarios con cierta frecuencia
El usuario se involucra más
Difícil de evaluar el coste total
Difícil de aplicar a sistemas transaccionales que
tienden a ser integrados y a operar como un todo
Requiere gestores experimentados
Los errores en los requisitos se detectan tarde.
El resultado puede ser muy positivo.
25. Consiste en iterar en la fase de análisis tantas veces como
sea necesario, mostrando prototipos al usuario para que
pueda indicarnos de forma mas eficiente los requisitos del
sistema.
26. Observaciones:
No modifica el flujo del ciclo de vida
Reduce el riesgo de construir productos que
no satisfagan las necesidades de los usuarios
Reduce costos y aumenta la probabilidad de éxito
Exige disponer de las herramientas adecuadas
No presenta calidad ni robustez
Una vez identificados todos los requisitos
mediante el prototipo, se construye el producto
de ingeniería.
27. PARA QUE SEA EFECTIVO:
Debe ser un sistema con el que se pueda
experimentar
Debe ser comparativamente barato (< 10%)
Debe desarrollarse rápidamente
Énfasis en la interfaz de usuario
Equipo de desarrollo reducido
Herramientas y lenguajes adecuados
“El prototipado es un medio excelente para recoger el
‘feedback’ (realimentación) del usuario final”
28. PELIGROS DEL PROTOTIPO
El cliente ve funcionando lo que para él es la
primera versión del prototipo que ha sido
construido con “plastilina y alambres”, y puede
desilusionarse al decirle que el sistema aun no ha
sido construido.
El desarrollador puede caer en la tentación de
ampliar el prototipo para construir el sistema
final sin tener en cuenta los compromisos de
calidad y de mantenimiento que tiene con el
cliente.
29. Proporciona potencial para desarrollo rápido de versiones
incrementales. En el modelo Espiral el software se construye
en una serie de versiones incrementales. En las primeras
iteraciones la versión incremental podría ser un modelo en
papel o bien un prototipo.
30. En cada vuelta o iteración hay que tener en cuenta:
Los Objetivos: qué necesidad debe cubrir el producto.
Alternativas: las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos de vista
como pueden ser:
Características: experiencia del personal, requisitos a
cumplir, etc.
Formas de gestión del sistema.
Riesgo asumido con cada alternativa.
Desarrollar yVerificar: Programar y probar el software.
31. Observaciones
Trata de mejorar los ciclos de vida clásicos y prototipos.
Permite acomodar otros modelos
Incorpora objetivos de calidad y gestión de riesgos
Elimina errores y alternativas no atractivas al comienzo
Permite iteraciones, vuelta atrás y finalizaciones rápidas
Cada ciclo empieza identificando:
▪ Los objetivos de la porción correspondiente
▪ Las alternativas
▪ Restricciones
Cada ciclo se completa con una revisión que incluye todo
el ciclo anterior y el plan para el siguiente.
32. Reconocimiento explícito de las diferentes
alternativas.
Identificación de riesgos para cada alternativa
desde el comienzo.
Al dividir el proyecto en ciclos, al final de cada
uno existe un acuerdo para los cambios que
hay que realizar en el sistema.
El modelo se adapta a cualquier tipo de
actividad adicional.
33.
34. Principios
Existen similitudes entre distintos sistemas de un mismo dominio
de aplicación
El software puede representarse como una combinación de módulos
Diseñar aplicaciones = especificar módulos + interrelaciones
Los sistemas nuevos se pueden caracterizar por diferencias respecto a
los antiguos
Reduce tiempos y costes de desarrollo
Aumenta la fiabilidad
Dificultad para reconocer los componentes potencialmente reutilizables
Dificultad de catalogación y recuperación
Problemas de motivación
Problemas de gestión de configuración.
35.
36. Se define el sistema utilizando un lenguaje
formal.
La implementación es automática, asistida por
el ordenador.
La documentación se genera de forma
automática.
El mantenimiento se realiza “por
sustitución” no mediante “parches”.
Dificultad en la participación del usuario.
Diseños poco optimizados.