Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Guia de Estudios 2 Corregida

Descargar como odt, pdf o txt
Descargar como odt, pdf o txt
Está en la página 1de 8

Universidad Nacional de Misiones

Licenciatura en Sistemas de Información


Analista en Sistemas de Computación
Profesorado Universitario en Computación

Introducción al Análisis de Sistemas


Ingeniería de Software I
Profesor: Ing. Selva Nieves Ivaniszyn

Guía de Estudio 2
Integrantes
Foto APELLIDO y Nombre correo electrónico
Nasadyk Fernando fernasadyk12@gmail.com

Rodrigues Sebastian mailto:seb4.rdgz@gmail.com

Página 1|8
Miño Lucas mailto:lucas.mino1508@gmail.c
om

Keingeski Noam noamxd1@gmail.com

Año 2022

Página 2|8
2.1. SUGIERA el modelo de proceso de software genérico más
adecuado que se use como fundamento para administrar el desarrollo de los
siguientes sistemas EXPLICANDO las razones para su respuesta, y con base en el
tipo de sistema a desarrollar (si son críticos o no críticos, si los requisitos cambiarán
frecuentemente o no, si los requisitos se dan en un escenario conocido o no, de
interfaz compleja o no, por ejemplo):

● Un sistema para controlar el antibloqueo de frenos en un automóvil.


i. A mi parecer, para este ejemplo, sugeriría el modelo de “El modelo en cascada”, por el hecho de
que los requisitos no cambiarían frecuentemente, y el escenario seria el mismo todo el tiempo, ya
que se establecerían en los vehículos, y agregando también que cuenta con los siguientes pasos:
a. Definición de requerimientos: En este paso se establecería todos los requerimientos que
debe de cumplir el sistema de control del antibloqueo de frenos vehicular, y se establece-
rían las pautas de seguridad del mismo.

b. Diseño del sistema y del software: Se diseñaría el sistema con las pautas establecidas en el
punto anterior.

c. Se implementa y se pone a prueba una unidad, estableciendo los errores y cambios a reali-
zar.

d. Se integra y se impone en fase de prueba en cantidad del sistema, colocando el sistema en


varios vehículos y administrando su correcto funcionamiento.

e. Se lanza oficialmente el sistema y obtiene mantenimiento con profesionales especializados


en el tema en el caso de que no obtenga un buen funcionamiento.

● Un sistema de realidad virtual para apoyar el mantenimiento de software.


i. Desde mi punto de vista, sugiero que el modelo de proceso de software que mas se adapta a este
ejemplo es el de “Desarrollo incremental“ ya que de este sistema se podría especificar su conteni-
do, desarrollarlo y ponerlo a prueba, y por lo tanto, al superar las pruebas, validarlo, y si el sistema
obtiene lo que debió obtener principalmente, al pasar del tiempo, desarrollar nuevas versiones del
mismo, ya que no es un software que de distribuya en sistemas mas avanzados o no se mantiene
desconectado de la red, al ser instalado por un operador, y mantenerse conectado a la red, podría
descargar las versiones actualizadas sin problemas.
Agregando que dicho sistema cambiaria sus requisitos frecuentemente, y no se podría conocer el
escenario en el que se establecería el sistema, este modelo de proceso de software vendría a ser el
mejor pensado en esta situación.
● Un sistema de contabilidad universitario que sustituya a uno existente.
i. En este caso en especial, sugeriría usar el modelo de proceso de software “ingeniería de software
orientada a la reutilización”, ya que, en este caso, el objetivo es sustituir un sistema de contabili-
dad universitario obsoleto, se podrá trabajar por encima del código de dicho sistema, ya que no se
perderían los datos del mismo y facilitaría la instalación del mismo en la universidad. En dicho
sistema los usuarios podrían criticar o no el sistema volviéndolo más accesible para los usuarios, y

Página 3|8
sabiendo que los requisitos no cambiarían frecuentemente, ya que serian los mis-
mos en todo momento, y a su vez, el escenario seria el mismo en todo momento, el
cual es la universidad.
● Un sistema interactivo de programación de viajes que ayude a los usuarios a planear viajes con el menor
impacto ambiental.
i. Por el hecho de que este sistema se planearía con gran cantidad de información y datos, sugeriría el mé-
todo de proceso de software “Desarrollo incremental” ya que el mismo podría ser desarrollado sobre una
base de información muy amplia y al pasar de los días, ser agregada mas información a través de las ver-
siones, agregando así nuevos métodos más eficientes de menor impacto ambiental y a su vez, agregar dis-
tintos destinos de viajes.

2.2. En lo referente al Desarrollo Incremental:


a. ¿CUÁLES son las características que presenta el Modelo Incremental para ser
considerado el enfoque más efectivo para diseñar Sistemas de Software
Empresariales?
b. ¿CUÁLES son los beneficios que presenta este Modelo respecto a otros?
c. ¿POR QUÉ este Modelo es menos adecuado para Ingeniería de Sistemas de
Tiempo Real?

a) El desarrollo incremental es mejor para el software empresarial porque refleja la forma en que se
resuelven los problemas, se avanza en una serie de pasos hacia la solución de los mismos, lo cual
permite retroceder cuando se detectaron errores.
b) Los beneficios que presenta este modelo con respecto a otros es que éste vincula las actividades de
especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones
(incrementos), y cada versión añade funcionalidad a la versión anterior.
c) Este modelo es menos adecuado para Ingeniería de Sistemas de Tiempo Real porque presenta la
dificultad de alterar los procesos empresariales normales, porque las entregas incrementales
requieren que se vaya usando el sistema sobre procesos reales.

2.3. CONSIDERE el Modelo de Proceso Basado en Reutilización que se muestra en la


figura 2.3.

a. EXPLIQUE POR QUÉ durante el proceso es esencial tener dos actividades


separadas de Ingeniería de Requerimientos.
• Es totalmente importante tener las “especificaciones de requerimientos” y las “modificaciones de
requerimientos” separadas en caso de que el usuario prefiera por complementar alguna de las aplicaciones
al sistema en desarrollo.

b. ¿CUÁLES son los Requisitos de Actividades de Ingeniería necesarios?


• Los requerimientos de actividades dependen del tipo del sistema, del personal y de la inclusión de
estructuras organizativas.
c. ¿EXISTEN etapas comparables con otros Procesos? ¿CUÁLES son comparables y
QUÉ etapas difieren de otros Procesos?
Si existen etapas comparables con otros procesos, las etapas que se comparan con otros procesos
son los de “especificación de requerimientos”, y a su vez, “Validación del sistema “. Estas etapas se
Página 4|8
comparan en gran manera, pero, a su vez, las etapas que difieren de otros procesos son las
etapas intermedias, como ser la etapa de “Análisis de componentes “, “Modificación de
requerimientos”, “Diseño de sistema con reutilización “y “Desarrollo e integración “, todas estas etapas
difieren de los demás procesos.

2.4. En el Proceso de Ingeniería de Requerimientos, es importante hacer una


distinción entre Desarrollar los Requerimientos del Usuario y Desarrollar los
Requerimientos del Sistema. a. ¿POR QUÉ es importante realizar esta
diferenciación? ¿Tienen necesidades diferentes? ¿CUÁLES? b. ¿CUÁLES son las
diferencias que fundamentan esta distinción?

A. Es importante realizar esta diferenciación porque el informe de los requerimientos tiene diferente
nivel de detalle para el usuario y para los requerimientos del sistema.

Tienen las mismas necesidades, simplemente que los usuarios tienen la información en general y
entendible de lo que el sistema hace y sus restricciones, por otra parte, el requerimiento del sistema
específica que es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables
con más detalle para él desarrollador.

B. La diferencia es el nivel de detalle y el lenguaje en el que se presentan cada requerimiento, además su


obtención, ya que en una se realiza discusiones con los usuarios finales, para poder comprender lo que el
sistema hará y realizar un informe abstracto, que luego, será analizado minuciosamente.

2.5 DESCRIBA las principales Actividades en el Proceso de Diseño de Software y las


Salidas de dichas Actividades. Con un diagrama, muestre las posibles relaciones
entre las Salidas de dichas actividades.
Las actividades en el proceso del diseño del software varían según el tipo de software, pero las principales
actividades que se realizan en el proceso de diseño del software son:
i. Diseño Arquitectónico: Se obtiene la estructura general del sistema, junto con sus componentes
principales, sus relaciones con otros sistemas y la forma de distribución.
la salida de esta actividad es una idea general del sistema completo, con detalles de lo que se espe-
ra a fin.

ii. Diseño de interfaz: Se establece la interfaz del sistema, entre los componentes del sistema, a inter-
faz no puede presentar errores o incertidumbres.
Una vez que se desarrollan las características del interfaz del sistema, los componentes son diseña-
dos y que se desarrollan, se obtiene una interfaz precisa y factible.

iii. Diseño de componentes: Se toma cada uno de los componentes que conforma el sistema para de-
sarrollarlos, con el fin de saber como funcionarán en el sistema y que se desea implementar en di-
cho sistema.
Si el componente es reutilizado, se debe de dejar una lista con todos los cambios o modelo de di-
seño detallado que deben ser implementado en dicho componente a reutilizar.
Al finalizar dicha actividad se obtiene como fin los componentes a utilizar con sus diseños y fun-
cionalidades para el sistema.

Página 5|8
2.6. En relación a las Actividades de Proceso de Software:
a. EXPLIQUE POR QUÉ el cambio es inevitable en los Sistemas
Complejos y CUÁL es la relación con el entorno.
El cambio es inevitable en los Sistemas Complejos ya que, constantemente se modifican los
requerimientos del sistema conforme la empresa procura que el sistema responda a presiones externas
que se modifican.
Por ejemplo: en una empresa al tener más clientes se debe implementar nuevos requerimientos en el
software por lo cual este cambiaría su modelo original.

b. MENCIONE ejemplos (además de la creación de Prototipos y la Entrega


Incremental), de Actividades de Proceso de Software que ayudan a predecir los
cambios y a lograr que el Software por desarrollar sea más resistente al cambio.
Desarrollar un sistema prototipo, para mostrar a los clientes algunas características clave del sistema y
que estos puedan experimentar con el prototipo y así poder perfeccionar el mismo.
Implementar los cambios en incrementos que aún no se desarrollen, así el proceso se diseña de modo
que los cambios no sean costosos.

2.7. En relación a los Prototipos:


a. EXPLIQUE en qué consiste un Prototipo.
Un prototipo es la primera versión o versión inicial de un sistema de software.

b. ¿CUÁL es la finalidad de utilizar Prototipos?


La finalidad de utilizar Prototipos es obtener una visión previa del proyecto, demostrar conceptos,
tratar opciones de diseño y encontrar posibles problemas y soluciones.

c. EXPLIQUE POR QUÉ los sistemas desarrollados como prototipos por lo


general no deben usarse como sistemas de producción.
Porque es una versión inicial de un software y aún no esta completado. Y en un prototipo se anticipan
los cambios en los cuales se van a implementar en el software por lo que aún no está terminado.

2.8. ANALICE el Modelo de Proceso de Software en Espiral de Boehm:


a. EXPLIQUE en qué consiste este Modelo.
Es un modelo de proceso de software evolutivo, representado por una espiral y dirigido por los
riesgos.

b. EXPONGA POR QUÉ el Modelo en Espiral de Boehm es un Modelo adaptable


que puede apoyar las actividades tanto de evitar el cambio como de tolerar el
cambio.
El modelo de Boehm nos dice que envía el cambio y lo tolera para poder reducir los riesgos ya que los
cambios son resultados de los riesgos, en este modelo podemos encontrar los problemas y podemos
retroceder para resolver los mismos.

c. ¿QUÉ lo diferencia de otros Modelos de Proceso de Software?


Lo que lo diferencia de otros modelos de proceso de software es su reconocimiento explícito del
riesgo.

d. En la práctica, este Modelo no se ha usado ampliamente. SUGIERA por qué


Página 6|8
éste podría ser el caso.
Porque el modelo de Boehm se basa en los riesgos y los riesgos conducen a
problemas de proyecto y al haber muchos problemas, habrá muchos cambios y por lo tanto habrá
exceso en las fechas y el costo del proyecto. Este modelo al tolerar el cambio resulta ser poco
eficiente frente a modelos que evitan el cambio.

iv. Diseño de base de datos: Se diseña o proyecta la base de datos del sistema, esto depende de que si
la base de datos se reutilizará o se creará desde cero una nueva base de datos.
Finalizando la actividad se obtendrá la base de datos del sistema.

2.9. ¿CUÁLES son las ventajas de proporcionar Visiones Estática y Dinámica del
Proceso de Software como en el Proceso Unificado Racional?

Las ventajas de proporcionar Visiones Estática y Dinámica del Proceso de Software como en el Proceso
Unificado Racional son:
• Poder asignar tareas y responsabilidades(quién es el que hace qué, cuándo lo hace y cómo lo
hace).
• Implementación de las mejores practicas en Ingeniería de Software de Desarrollo iterativo.
• Administración de requerimientos de software.
• Uso de una arquitectura que se basa es componentes de control de cambios.
• Visualización del software.

2.10. Históricamente, la introducción de la tecnología ha causado profundos cambios


en el mercado laboral y, al menos temporalmente, ha reemplazado a personas en los
puestos de trabajo. EXPLIQUE si es probable que la introducción de extensos
procesos de automatización tenga las mismas consecuencias para los Ingenieros de
Software. Si no cree que haya consecuencias, EXPLIQUE POR QUÉ. Si cree que
reducirá las oportunidades laborales, ¿ES ético que los Ingenieros afectados resistan
pasiva o activamente la introducción de esta tecnología?

Página 7|8
Desde mi opinión, no creo que la automatización reemplace el puesto de trabajo para los
Ingenieros de Software, ya que debe haber expertos con sus capacidades para diseñar
sistemas de calidad siguiendo los modelos necesarios y desempeñando su nivel en cada etapa de dicho
proceso.

Página 8|8

También podría gustarte