Ingenieria de Software

DIVISIÓN DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
PORTAFOLIO DE EVIDENCIAS DE
ADMINISTRACION DE BASE DE DATOS
FOLDER DE INGENIERIA DE SOFTWARE
Nombre del alumno

AQUINO HURTADO JESUS ROBERTO
Nombre del docente
JIMENEZ OLIVERA VIOLETA ROCIO
Grupo
362-V
2018-1
"Los ordenadores son como los bikinis. Ahorran a la gente el hacer muchas
conjeturas" Sam Ewing
Ilustración 1 The Software ................................................................................................................................. 4

Ilustración 2 Evolución....................................................................................................................................... 5
Ilustración 3 Ciclo .............................................................................................................................................. 7
Ilustración 4 Ciclo de vida .................................................................................................................................. 8
Ilustración 5 Modelo cascada ............................................................................................................................. 8
Ilustración 6 Requisitos de Software ................................................................................................................ 10
Contenido
 ¿QUÉ ES LA INGENIERÍA DE SOFTWARE?................................................................................... 3
 INTRODUCCIÓN ................................................................................................................................ 3
 HISTORIA................................................................................................................................................. 3
 OBJETIVOS DE LA INGENIERÍA DE SOFTWARE ............................................................................. 5
 CICLO DE VIDA DEL 'SOFTWARE' ..................................................................................................... 5
 MODELOS DEL PROCESO DE SOFTWARE ........................................................................................ 7
 MODELO EN CASCADA ........................................................................................................................ 8
 INGENIERÍA DE REQUISITOS SOFTWARE ..................................................................................... 10
 METODOS DE ANÁLISIS DE REQUERIMIENTOS .......................................................................... 12
 TÉCNICAS PARA IDENTIFICAR REQUISITOS FUNCIONALES Y NO FUNCIONALES ............ 13
 BIBLIOGRAFÍA ..................................................................................................................................... 16
06/03/2018 05:32:59 p.m.2

 ¿QUÉ ES LA INGENIERÍA DE SOFTWARE?
La ingeniería de software es una disciplina formada por un conjunto de métodos,

herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos
(software).
Esta disciplina trasciende la actividad de programación, que es el pilar fundamental a la
hora de crear una aplicación. El ingeniero de software se encarga de toda la gestión del
proyecto para que éste se pueda desarrollar en un plazo determinado y con el
presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño
del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementación del sistema.
 INTRODUCCIÓN
La ingeniería del software, según la definición de la IEEE en 1993, es la aplicación de un

enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento
del software. La ingeniería del software ofrece métodos o técnicas para desarrollar y
mantener software de calidad que resuelven problemas de todo tipo, y trata áreas muy
diversas de la informática y de las ciencias computacionales.
 HISTORIA
El concepto de ingeniería del software surgió en 1968, tras una conferencia en Garmisch
(Alemania) que tuvo como objetivo resolver los problemas de la crisis del software. El
término crisis del software se usó desde finales de 1960 hasta mediados de 1980 para
describir los frecuentes problemas que aparecían durante el proceso de desarrollo de
nuevo software. Tras la aparición de nuevo hardware basado en circuitos integrados,
comenzaron a desarrollarse sistemas y aplicaciones mucho más complejos que hasta
entonces no era posible construir puesto que el hardware disponible no lo permitía. Estos
nuevos proyectos de desarrollo de software, en la mayoría de ocasiones, no se
terminaban a tiempo, lo cual también provocaba que el presupuesto final del software
excediera de aquel que se había pactado. Algunos de estos proyectos eran tan críticos
(sistemas de control de aeropuertos, equipos para medicina, etc.) que sus implicaciones
iban más allá de las pérdidas millonarias que causaban. Además, en muchos casos el
software no daba respuesta a las verdaderas necesidades del cliente o había que ser un
usuario experto para poder utilizarlo, todo ello sumado a que el mantenimiento de los
productos era complejo y muy costoso.
06/03/2018 05:32:59 p.m.3

Ilustración 1 The Software
El software no se producía como el hardware, que tenía un proceso de fabricación

definido y dividido en fases. El resultado eran productos de pésima calidad en los que se
habían invertido mucho tiempo y dinero pero que o bien no llegaban a terminarse o bien a
la larga no daban el resultado que se esperaba. Se detectó que los métodos de desarrollo
de software informales que hasta entonces habían bastado para proyectos pequeños no
eran suficientes para los nuevos y grandes proyectos, y que se necesitaban profesionales
especializados en esta nueva disciplina que fueran capaces de lidiar con la creciente
complejidad de los nuevos sistemas.
Una de las primeras y más conocidas referencias a los conceptos crisis el software e
ingeniería del software fue hecha por Edsger Dijkstra, durante la presentación de 1972
titulada “The Humble Programmer” en la Association for Computing Machinery, cuando se
le hizo entrega de un Premio Turing. (Edsger Dijkstra)
 EVOLUCIÓN DE LA INGENIERÍA DEL SOFTWARE
Con el transcurso de los años se han desarrollado recursos que conforman la ingeniería
del software, es decir, herramientas y técnicas de especificación, diseño e implementación
del software: la programación estructurada, la programación orientada a objetos, las
herramientas CASE, la documentación, los estándares, CORBA, los servicios web, el
lenguaje UML, etc.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los
métodos formales al desarrollo de software, argumentando que si se probaba
formalmente que los productos software hacían lo que se les requería, la industria del
software sería tan predecible como lo son otras ramas de la ingeniería.
06/03/2018 05:32:59 p.m.4

Ilustración 2 Evolución
 OBJETIVOS DE LA INGENIERÍA DE SOFTWARE
En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver

los problemas, la informática aporta herramientas y procedimientos sobre los que se
apoya la ingeniería de software.
Mejorar la calidad de los productos de software

Aumentar la productividad y trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases para construir software de alta calidad en una
forma eficiente.
Definir una disciplina que garantice la producción y el mantenimiento de los productos
software desarrollados en el plazo fijado y dentro del costo estimado.
 CICLO DE VIDA DEL 'SOFTWARE'
El término ciclo de vida del software describe el desarrollo de software, desde la fase
inicial hasta la fase final. El propósito de este programa es definir las distintas fases
intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para
garantizar que el software cumpla los requisitos para la aplicación y verificación de los
procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que
se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los
errores se detecten lo antes posible y, por lo tanto, permite a los desarrolladores
concentrarse en la calidad del software, en los plazos de implementación y en los costos
asociados.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
06/03/2018 05:32:59 p.m.5

Definición de objetivos: Define la finalidad del proyecto y su papel en la estrategia

global.
Análisis de los requisitos y su viabilidad: Recopila, examina y formula los requisitos

del cliente y examina cualquier restricción que se pueda aplicar.
Diseño general: Requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: Definición precisa de cada subconjunto de la aplicación.
Programación (programación e implementación): Implementación de un lenguaje de

programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: Prueba individual de cada subconjunto de la aplicación para

garantizar que se implementaron de acuerdo con las especificaciones.
Integración: Garantiza que los diferentes módulos se integren con la aplicación. Este es
el propósito de la prueba de integración que está cuidadosamente documentada.
Prueba beta (o validación): Garantiza que el software cumple con las especificaciones
originales.
Documentación: Sirve para documentar información necesaria para los usuarios del
software y para desarrollos futuros.
Implementación.
Mantenimiento: Comprende todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el
equipo de desarrolladores.
06/03/2018 05:32:59 p.m.6

Ilustración 3 Ciclo
 MODELOS DE CICLO DE VIDA DEL 'SOFTWARE'
Para facilitar una metodología común entre el cliente y la compañía de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas y la documentación requerida, de manera que cada etapa se valide antes de
continuar con la siguiente.
 MODELOS DEL PROCESO DE SOFTWARE
El modelo de proceso de desarrollo de software es quizás la pieza más importante de este

engranaje conocido como ingeniería de software. Existen varios modelos para el proceso
de desarrollo software. Los modelos están conformados por etapas que son generales a
todos los enfoques. Las diferencias están básicamente en los tiempos en los cuales se
realizan dichas etapas, la simultaneidad, la prioridad que se le da a cada etapa, entre
otros elementos. Otras características se pueden observar en detalle en la definición de
cada uno de los modelos.
06/03/2018 05:32:59 p.m.7

Ilustración 4 Ciclo de vida
La figura muestra el ciclo de vida que debe cumplir un software que da paso al tiempo de vida que este pueda
adquirir con la implementación de los modelos del proceso de la ingeniería del software.
 MODELO EN CASCADA
Modelo en cascada el más conocido, está basado en el ciclo convencional de una
ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades.
Ilustración 5 Modelo cascada
Esta figura representa la serie de fases que se ejecutan secuencialmente.
 REPRESENTACIÓN DEL MODELO EN CASCADA

Se desarrolla el software en etapas y que después del término de una etapa no es posible
regresar a ella, este modelo tiene cuatro etapas que son:
06/03/2018 05:32:59 p.m.8

- Planificación: se determinan los objetivos, metas, requerimientos y restricciones en el

proyecto.
- Análisis de riesgos: identificación de situaciones inconvenientes para evitarlas y
solucionarlas.
- Ingeniera: desarrollo del producto con respecto al diseño y otras consideraciones
planteadas.
- Evaluación del cliente: valorización de los resultados del proyecto (producto obtenido).
El modelo en lineal secuencial es también conocido como el ciclo de vida del software,
está conformado por las etapas de Análisis de requerimientos, Diseño, Codificación y
pruebas. Cada etapa tiene dependencias de finalización y orden la una de la otra. En ese
orden de ideas no se podrá iniciar la etapa de codificación sino no se ha pasado ya por la
etapa de análisis y diseño previamente y respectivamente.
Debido a la forma en la que este proceso aborda la solución de proyectos software tiene
algunas ventajas y falencias.
-Análisis de requerimientos: en esta etapa se procede a recopilar todos los requisitos que
debe cumplir el software a desarrollar, el cliente aquí tiene un papel fundamental, ya que
analiza junto con los desarrolladores del software los requisitos que debe cumplir el
software a desarrollar.
- Diseño: esta etapa está enfocada hacia el desarrollo de un esbozo de la arquitectura, la

interfaz y el manejo de datos del software.
- Generación de código: es cuando se implementa el diseño del software en algún

lenguaje de programación definido en el mismo diseño.
- Pruebas: se hace una revisión de los procesos que realiza el software, para determinar
que esté haciendo lo planteado para cumplir con los requerimientos.
- Mantenimiento: se verifica el correcto funcionamiento del software en su entorno de uso,

y si existen errores o defectos, proceden a corregirlos
DESVENTAJAS:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre
hay iteraciones y se crean problemas en la aplicación del paradigma.
Normalmente, es difícil para el cliente establecer explícitamente al principio todos los

requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos productos.
VENTAJA:
La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software-
06/03/2018 05:32:59 p.m.9

 INGENIERÍA DE REQUISITOS SOFTWARE
La ingeniería de requisitos software consiste en el proceso que permite identificar los

servicios y restricciones que formarán un sistema software.
Según la IEEE un requisito es:
Una condición o capacidad requerida por un usuario para resolver un problema o alcanzar
un objetivo.
Una condición o capacidad que debe cumplir o poseer un sistema o componente de
sistema para satisfacer un contrato, estándar, especificación, o cualquier otro documento
impuesto formalmente.
Una representación documentada de una condición o capacidad de lo explicado en los
puntos 1 o 2.
IEEE Standard Glosary of Software Engineering Terminology. IEEE Computer Society
Press. 1990. (IEEE Computer Society Press. 1990)
Ilustración 6 Requisitos de Software
Los requisitos pueden dividirse en:
Requisitos de usuario: Son frases en lenguaje natural o descripciones gráficas

(diagramas) de los servicios que se espera que ofrezca el sistema y de sus restricciones.
Requisitos de sistema: Una descripción más detallada de los servicios exactos que se
proporcionarán y sus restricciones. Estos requisitos sirven como contrato con el cliente. A
su vez los requisitos de sistema pueden dividirse en requisitos funcionales, no funcionales
y de dominio.
Requisitos funcionales: Especifican lo que debe hacer o los servicios que debe
proporcionar el sistema. Ejemplo: en un software de gestión de una biblioteca podrían ser
requisitos funcionales dar de alta un cliente, alquilar un libro, devolver un libro, comprar un
06/03/2018 05:32:59 p.m.10

libro, etc. Los requisitos funcionales deben describir también cómo responderá el sistema
ante estas distintas entradas, y su comportamiento frente a situaciones particulares.
Requisitos no funcionales: Son restricciones de los servicios del sistema o funciones que
ofrece. Ejemplo: en un software de gestión de compras de una tienda podrían ser
requisitos no funcionales un tpv para pagar con tarjeta, un PC con memoria y espacio en
disco para almacenar la base de datos de ventas, que sea capaz de atender a la vez a
varios clientes, que no tarde más de X tiempo en gestionar una venta, etc.
Requisitos de dominio: Estos requisitos reflejan características del dominio de la
aplicación. Ejemplo: la forma en la que se comunicarán distintas partes de la aplicación, el
tipo de datos con los que trabajará, etc.
 IMPORTANCIA DE LA INGENIERÍA DE REQUISITOS
Permite gestionar las necesidades del proyecto en forma estructurada

Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados
Disminuye los costos y retrasos del proyecto
Mejora la calidad del software
Mejora la comunicación entre equipos
Evita rechazos de los usuarios finales
 ACTIVIDADES DE LA INGENIERÍA DE REQUISITOS
Actividades cíclicas que cumplen una buena práctica de ingeniería de requisitos.
Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre

comúnmente dado a las actividades involucradas en el descubrimiento preliminar de los
requisitos de usuario.
Estudio de viabilidad: En esta fase se estima si el problema del usuario se podrá

resolver con la tecnología disponible y si el sistema será rentable según el presupuesto
del que se dispone.
Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la

cual se interactúa con clientes o usuarios para determinar los requisitos funcionales y
funcionales del sistema, además del dominio de la aplicación.
Especificación: En esta fase se documentan los requisitos con mayor detalle y precisión,
de manera que sirva de base para un contrato entre el desarrollador y el cliente.
Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos,
es decir, verificar todos los requisitos que aparecen en el documento especificado para
asegurarse de que son aceptados por el cliente. Esto implica verificar que los requisitos
sean consistentes, que estén completos, que sean realistas y que puedan ser verificables.
06/03/2018 05:32:59 p.m.11

 METODOS DE ANÁLISIS DE REQUERIMIENTOS
 METODO DE PRESSMAN
Para Pressman, en el proceso de análisis de requerimientos del software se puede

identificar cinco tareas o etapas fundamentales:
Reconocimiento del problema: Se basa en el estudio inicial de las especificaciones del

sistema y el plan del proyecto del software. El analista debe establecer un canal adecuado
de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la
función primordial del analista en todo momento es reconocer los elementos del problema
tal y como los percibe el usuario.
Evaluación y síntesis: Se centra en el flujo y estructura de la información, definir las

funciones del software, determinar los factores que afectan el desarrollo de nuestro
sistema, establecer las características de la interfaz del sistema y descubrir las
restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la
determinación del problema de forma sintetizada.
Modelización: Se basa en la creación de modelos del sistema que servirán para

comprender mejor el proceso funcional, operativo y de contenido de la información. El
modelo servirá de pilar para el diseño del software y como base para la creación de una
especificación del software.
Especificación: Las tareas asociadas con la especificación intenta proporcionar una

representación del software. Esto más adelante permitirá llegar a determinar si se ha
llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar
plasmados manuales.
Revisión: Es la etapa final del levantamiento de requisitos y se enfoca en demostrar que

se ha llegado a un buen entendimiento de la forma de implementar con éxito el software.
La documentación del análisis de requerimientos y manuales, permitirán una revisión por
parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del
sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas
inicialmente.
 METODO DE CORE
Existen metodologías alternas como el Método CORE (Controlled Requirements

Expression) que plantean un escenario más tecnico al realizar una ingeniería de
requerimientos sobre un software. Este método es un conjunto de notaciones textuales y
gráficas, con guías especificadas para la captura y validación de requerimientos del
sistema, en las etapas iniciales del diseño del sistema.Es pensado como puramente una
técnica de captura y análisis de requerimientos, aunque soporta algunos aspectos de
diseño tales como estructuras de datos. CORE está basada en el principio de primero
definir el problema a ser analizado y luego dividirlo en unidades o puntos de vista a
considerar.
06/03/2018 05:32:59 p.m.12

Esta metodología se basa en 7 aspectos:
Definición del problema: El propósito de la definición del problema es identificar los

límites del mismo. Contiene detalles de los objetivos de la empresa de los usuarios del
sistema, la base para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y
quién va a ser el responsable de la revisión y aceptación de los resultados finales.
Estructuración del punto de vista: El propósito de esta etapa es descomponer el

ambiente del sistema en los elementos para que el sistema propuesto pueda ser
analizado desde los puntos de vista de todas las entidades que se comunican con él, la
más importante de las cuales son los usuarios. Durante esta etapa, todas las entidades
que son fuentes potenciales de información deben ser identificadas.
Colección tabular: Esta etapa es cuando la información sobre los flujos de datos entre
los puntos de vista y el procesamiento de éstos son reunidos. Esto ayuda a establecer la
totalidad y consistencia.
Estructuración de datos: En la etapa previa, los elementos de información que pasan
entre los puntos de vista son referidos por sus nombres generales. En esta etapa, se da
una vista más cercana al contenido, a la estructura y a la derivación de datos, al producir
diagramas de estructura de datos.
Modelación individual de puntos de vista: Esta etapa puede dividirse en dos partes. Lo
único concerniente a la primera es convertir las TCF'S en una notación diferente para
producir los diagramas individuales del modelo de punto de vista. La segunda parte se
refiere a agregar alguna información nueva perteneciente a flujos de datos internos,
control de acciones y tiempo de acciones.
Modelación combinada de punto de vista: Esta etapa facilita el análisis de una

secuencia de eventos de más de un punto de vista. Cada diagrama de modelo combinado
de punto de vista producido durante esta etapa es una representación del procesamiento
de información que ocurre entre puntos de vista.
Análisis de restricciones: En esta etapa, se consideran restricciones adicionales tales

como desempeño y seguridad. Éstas pueden afectar los diagramas de puntos de vista ya
producidos. Las restricciones se documentan en una especificación de restricción del
sistema.
 TÉCNICAS PARA IDENTIFICAR REQUISITOS FUNCIONALES Y NO

FUNCIONALES
Ya que los requerimientos de sistemas de software se clasifican en funcionales y no

funcionales, se deben tener en cuenta las siguientes técnicas para la identificación
correcta.
06/03/2018 05:32:59 p.m.13

 IDENTIFICACIÓN DE REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales son declaraciones de los servicios que proveerá el

sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos,
los requerimientos funcionales de los sistemas también declaran explícitamente lo que el
sistema no debe hacer.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la

especificación de requerimientos. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación.
Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos
requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e
incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La compleción significa que todos los servicios solicitados por
el usuario están definidos. La consistencia significa que los requerimientos no tienen
definiciones contradictorias.
En la práctica, para sistemas grandes y complejos, es imposible cumplir los

requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la
complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista
tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los
requerimientos se especifican por primera vez. Los problemas emergen después de un
análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o
en las fases posteriores del ciclo de vida, se deben corregir en el documento de
requerimientos.
 IDENTIFICACIÓN DE REQUERIMIENTOS NO FUNCIONALES
Son aquellos requerimientos que no se refieren directamente a las funciones específicas

que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la
respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen
las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la
representación de datos que se utiliza en la interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las

restricciones en el presupuesto, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a factores externos como
los reglamentos de seguridad, las políticas de privacidad, entre otros.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como los

requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria
se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable;
los de portabilidad y los de usabilidad.
06/03/2018 05:32:59 p.m.14

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador: estándares en los
procesos que deben utilizarse; requerimientos de implementación como los lenguajes de
programación o el método de diseño a utilizar, y los requerimientos de entrega que
especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso

de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en
que el sistema interactúa con los otros sistemas de la organización; los requerimientos
legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los
requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será
aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no

les es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas,
como las de mantenimiento, no existen métricas que se puedan utilizar; el costo de
verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el

documento de requerimientos. En la práctica, esto es difícil. Si un requerimiento no
funcional se declara de forma separada a los funcionales, algunas veces es difícil ver la
relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil separar
las condiciones funcionales y no funcionales e identificar los requerimientos que se
refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del
tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren
a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos
en una sección aparte o diferenciándolos, de alguna forma, de los otros requerimientos
del sistema.
06/03/2018 05:32:59 p.m.15

 BIBLIOGRAFÍA
http://www.monografias.com/docs114/modelos-ingenieria-del-software/modelos-
ingenieria-del-software.shtml
https://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/
https://es.wikiversity.org/wiki/Ingenier%C3%ADa_de_requisitos_software
 REFERENCIAS
IEEE Computer Society Press. 1990
(Edsger Dijkstra)
06/03/2018 05:32:59 p.m.16

Ingenieria de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software

Cargado por

Copyright:

Formatos disponibles

DIVISIÓN DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

FOLDER DE INGENIERIA DE SOFTWARE

Nombre del alumno

Ilustración 1 The Software ................................................................................................................................. 4

06/03/2018 05:32:59 p.m.2

 ¿QUÉ ES LA INGENIERÍA DE SOFTWARE?

La ingeniería de software es una disciplina formada por un conjunto de métodos,

La ingeniería del software, según la definición de la IEEE en 1993, es la aplicación de un

06/03/2018 05:32:59 p.m.3

Ilustración 1 The Software

El software no se producía como el hardware, que tenía un proceso de fabricación

 EVOLUCIÓN DE LA INGENIERÍA DEL SOFTWARE

06/03/2018 05:32:59 p.m.4

 OBJETIVOS DE LA INGENIERÍA DE SOFTWARE

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver

Mejorar la calidad de los productos de software

 CICLO DE VIDA DEL 'SOFTWARE'

El ciclo de vida básico de un software consta de los siguientes procedimientos:

06/03/2018 05:32:59 p.m.5

Definición de objetivos: Define la finalidad del proyecto y su papel en la estrategia

Análisis de los requisitos y su viabilidad: Recopila, examina y formula los requisitos

Diseño general: Requisitos generales de la arquitectura de la aplicación.

Diseño en detalle: Definición precisa de cada subconjunto de la aplicación.

Programación (programación e implementación): Implementación de un lenguaje de

Prueba de unidad: Prueba individual de cada subconjunto de la aplicación para

Mantenimiento: Comprende todos los procedimientos correctivos (mantenimiento

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

06/03/2018 05:32:59 p.m.6

 MODELOS DE CICLO DE VIDA DEL 'SOFTWARE'

 MODELOS DEL PROCESO DE SOFTWARE

El modelo de proceso de desarrollo de software es quizás la pieza más importante de este

06/03/2018 05:32:59 p.m.7

Ilustración 4 Ciclo de vida

Ilustración 5 Modelo cascada

Esta figura representa la serie de fases que se ejecutan secuencialmente.

 REPRESENTACIÓN DEL MODELO EN CASCADA

06/03/2018 05:32:59 p.m.8

- Planificación: se determinan los objetivos, metas, requerimientos y restricciones en el

- Diseño: esta etapa está enfocada hacia el desarrollo de un esbozo de la arquitectura, la

- Generación de código: es cuando se implementa el diseño del software en algún

- Mantenimiento: se verifica el correcto funcionamiento del software en su entorno de uso,

Normalmente, es difícil para el cliente establecer explícitamente al principio todos los

06/03/2018 05:32:59 p.m.9

 INGENIERÍA DE REQUISITOS SOFTWARE

La ingeniería de requisitos software consiste en el proceso que permite identificar los

Según la IEEE un requisito es:

Ilustración 6 Requisitos de Software

Los requisitos pueden dividirse en:

Requisitos de usuario: Son frases en lenguaje natural o descripciones gráficas

06/03/2018 05:32:59 p.m.10

 IMPORTANCIA DE LA INGENIERÍA DE REQUISITOS

Permite gestionar las necesidades del proyecto en forma estructurada

 ACTIVIDADES DE LA INGENIERÍA DE REQUISITOS

Actividades cíclicas que cumplen una buena práctica de ingeniería de requisitos.

Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre

Estudio de viabilidad: En esta fase se estima si el problema del usuario se podrá

Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la

06/03/2018 05:32:59 p.m.11

 METODOS DE ANÁLISIS DE REQUERIMIENTOS

Para Pressman, en el proceso de análisis de requerimientos del software se puede

Reconocimiento del problema: Se basa en el estudio inicial de las especificaciones del

Evaluación y síntesis: Se centra en el flujo y estructura de la información, definir las

Modelización: Se basa en la creación de modelos del sistema que servirán para

Especificación: Las tareas asociadas con la especificación intenta proporcionar una