INGENIERÍA DE SOFTWARE: Ingeniería de requisitos parte || (Primer documento)

5 ideas principales
• -Los ingenieros de software trabajan con una variedad de stakeholders del
sistema para obtener información acerca del dominio de la aplicación, los servicios
que debe proporcionar el sistema, los requisitos de performance del sistema,
restricciones de hardware, otros sistemas, etc.
Básicamente los ingenieros de software realizan la obtención de requisitos sobre
el software, es decir, lo que este tendrá que hacer, por ende, los stakeholders lo
que harán es comunicar los requisitos del software, aquí aplica el descubrimiento y
relevamiento de los mismos, a su vez, haciendo la clasificación y organización de
requisitos, priorización y negociación de requisitos y la especificación de los
mismos, para el correcto desarrollo del software.
• -La manera más obvia de averiguar que necesitan los usuarios de un
sistema de software es preguntarles a ellos.
Esta sería una técnica para obtener requisitos, la que radica principalmente en las
entrevistas, usándolas para entender el problema del negocio, entender el
ambiente de operación, evitar omisión de requisitos y mejorar las relaciones con el
cliente, de manera que en cada cita que se tenga con el mismo cliente, se
empiece a concretar de manera satisfactoria el desarrollo del software y evitar
complicaciones después
• -Implican observar a los usuarios mientras realizan sus actividades. Pueden
ser silenciosas o interactivas.
Básicamente esto aplica dentro de la técnica de observaciones, por lo que, en
general los usuarios no son muy precisos al describir sus tareas. Esto puede ser
porque son tareas complejas y difíciles de explicar. En otros casos, están tan
familiarizados que omiten detalles de forma inconsciente.
• -Examinar los otros sistemas con los que se conecta el sistema.
Sería el analizar las interfaces del sistema donde el sistema que estaremos
desarrollando se conecta, dado que cada sistema que se deba comunicar con el
nuestro se identifican las funcionalidades que nos puedan generar requisitos y
esos requisitos pueden describir los datos a pasar a otros sistemas, los datos a
recibir de otros sistemas y las reglas sobre los datos.
• -Que el cliente piense que el producto ya está pronto. O que quiera una
versión para probarlo fuera de la instancia de validación.
Este si bien es un riesgo de implementar prototipos, dado que se puede dar la
situación de que el cliente piense que ya es el software desarrollado y tome una
decisión impulsiva o vaya de lleno a que así lo quiere o que quiere probar las
funcionalidades del software, lo cual podría ser contraproducente, dado que el
cliente puede perderse en los detalles y generar expectativas irreales con respecto
al producto final.

Procesos de software
5 ideas principales
-El proceso de software es un conjunto estructurado de actividades requeridas
para desarrollar software
Como tal existen muchos diferentes procesos de software, pero todos involucran
la especificación en diseño e implementación, la validación y la evolución
-el modelo de integración y configuración se basa en integrar componentes
existentes o integrar sistemas corts que significa commerce of the south.
los elementos reciclados pueden configurarse para adaptar el comportamiento de
funcionalidad para los requisitos de un usuario, este es el tipo de modelo estándar
que se utiliza actualmente para desarrollar muchos sistemas. Por ejemplo, si
necesitamos hacer una página web, podemos hacer le ciclo de especificación y
refinación de requerimientos con el cliente, de ahí descubrir si fue disponible y
evaluarlo para que cumpla con lo que el cliente necesita.
-Procesos de ingeniería de requerimientos, siendo un proceso de establecer qué
servicios son requeridos y cuales son las limitaciones del sistema en cuanto a
operación y desarrollo
Básicamente es presentar los servicios que están al alcance para implementar la
fase de desarrollo de software, según los servicios que se requieran, pero por
parte de ello, estableciendo las limitaciones del mismo sistema, ya sea en la fase
del desarrollo o de las operaciones que se realicen para la creación del sistema o
del mismo sistema. Consistiendo de la licitación y análisis de requerimientos, que
son las mismas cosas que el cliente necesita o espera del sistema.
-Reducir los costos de factorización se debe de aplicar la anticipación al cambio y
la tolerancia al cambio
Siendo que la anticipación al cambio, son los procesos de software que incluyen
actividades que pueden anticipar los cambios que se van a realizar, antes de que
una refactorización sea necesaria, por otra parte, la tolerancia al cambio, implica
que los procesos son diseñados de tal manera que los cambios pueden ser
introducidos con un costo relativamente bajo, esto normalmente, es una forma de
desarrollo incremental de los cambios.
- Las mejoras de procesos, significan realmente entender los procesos
existentes
La manera de implementar la mejora de procesos, es a través de la madurez del
proceso, que mejorar los procesos e introducir buenas prácticas de ingeniería de
software, por otra parte, el acercamiento ágil, se concentra en desarrollo
interactivo y la reducción de gastos generales en los procesos de software
PROCESOS
5 ideas principales
-Modelo lineal secuencial el cual también es llamado “ciclo de vida clásico” o
“modelo en cascada”, sugiere un enfoque sistemático
Es decir, para el desarrollo del software que empieza con el establecimiento de
requisitos y pasa a las fases de análisis, diseño, codificación, pruebas y
mantenimiento.
-El software puede necesitar cambios, debido a varias razones: errores, el entorno
o mejoras sugeridas por el cliente.
Más que nada referible a al mantenimiento que se le puede realizar al software,
según si es necesario implementárselo, ya sea por las situaciones descritas
(errores, el entorno o mejoras sugeridas por el cliente) o por alguna otra razón en
específico.
-El modelo espiral, propuesto originalmente por B. Boehm, es un modelo de
proceso de software evolutivo que conjuga la naturaleza iterativa de construcción
de prototipos con los aspectos controlados y sistemáticos del modelo en cascada,
añadiendo un nuevo elemento: el análisis de riesgo.
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las
alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis
de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la
creación de prototipos en el cuadrante de ingeniería para dar asistencia, tanto al
encargado de desarrollo como al cliente. Éste evalúa el trabajo de ingeniería
(cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de
los comentarios del cliente se produce la siguiente fase de planificación y de
análisis de riesgo; en cada bucle alrededor de la espiral, la culminación del análisis
de riesgo resulta en una decisión de “seguir o no seguir”.