Tecnologico de Estudios Superiores de Valle de Bravo

OPCIÓN DE TITULACIÓN
TECNOLOGICO DE ESTUDIOS SUPERIORES DE VALLE DE BRAVO
INGENIERÍA EN SISTEMAS COMPUTACIONALES
INGENIERIA DE SOFTWARE
RESUMEN UNIDAD 1
PRESENTA:
ANDREA ADANALY SUÁREZ ESTRELLA
PROFESOR:
M.I.S.C. PRIMERO HUERTA CÉSAR

Revisión de especificación de requisitos.
El análisis de requisitos es una de las tareas más importantes en el ciclo de vida de
desarrollo de software, puesto que en ella se determinan los “planos” de la nueva
aplicación.
Los principales objetivos que se identifican en la especificación de requisitos software son:
Los principales objetivos que se identifican en la especificación de requisitos software son
1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

determinado software: El cliente debe participar activamente en la especificación de
requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se
llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.
2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En
muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS
permite al cliente definir todos los requisitos que desea y al mismo tiempo los
desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena
especificación de requisitos, los costes de desarrollo pueden incrementarse
considerablemente, ya que se deben hacer cambios durante la creación de la
aplicación.
3. Servir de base para desarrollos de estándares de ERS particulares para cada
organización: Cada entidad puede desarrollar sus propios estándares para definir sus
necesidades.
1.1.1Norma IEEE830
La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe decirlas de
una determinada manera. En este documento se presentará una de las formas que viene
especificada por el estándar IEEE 830. Una ERS forma parte de la documentación asociada
al software que se está desarrollando, por tanto, debe definir correctamente todos los
requerimientos, pero no más de los necesarios.
Existen 3 tipos de requisitos específicos :

 Comunes interfaz
 Funcionales
 No funcionales
Esta documentación no debería describir ningún detalle de diseño, modo de
implementación o gestión del proyecto, ya que los requisitos se deben describir de forma
que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los
desarrolladores para la implementación. Así pues, el grado y el lenguaje utilizado para la
documentación de los requisitos estarán en función del nivel que el usuario tenga para
entender dichas especificaciones.
Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que se
indican en el IEEE son las siguientes:
 Correcta
 No ambigua
 Completa
 Verificable
 Consistente
 Clasificada
 Modificable
 Explorable
 Utilizable durante las tareas de mantenimiento y uso
1.1.2Trazabilidad de requisitos
El Proceso Unificado es un proceso de desarrollo adoptado por gran parte de las empresas
desarrolladoras de software. Esto lleva a que atributos de calidad como la trazabilidad de
requisitos deban estandarizarse para este proceso, con el fin de lograr los niveles de calidad
exigidos por los clientes. Por lo general, los modelos de trazabilidad se proponen
independientemente del proceso o métodos de desarrollo, y su definición y mantenimiento
dependen de los criterios de calidad usados por los desarrolladores. En este artículo se
presenta un método para la práctica de la trazabilidad en el Proceso Unificado de
desarrollo. El enfoque propone un flujo de trabajo para el control y soporte a la trazabilidad
en las iteraciones del proceso. Dicho flujo establece un conjunto de acciones para generar
modelos de trazabilidad que faciliten negociaciones oportunas con los participantes del
proyecto.
Los métodos de desarrollo de software son variados y tienen características propias que los
hacen aptos y específicos para las necesidades de los desarrolladores. Sin embargo,
independientemente de cuál se utilice y los productos de trabajo (workproducts) o
artefactos que de él se deriven, los elementos que apoyan el proceso de desarrollo son
susceptibles de ser trazados. El grado de trazabilidad que se puede lograr depende de
factores tales como la cantidad y calidad de información que proporcionan los elementos de
modelo y las necesidades de los participantes del proyecto en la gestión que se deriva de la
traza.
El Proceso Unificado (UP), conocido comercialmente como RUP –Rational Unified

Process–, constituye un marco de trabajo o metodología estándar de desarrollo ampliamente
usado y difundido en las empresas de desarrollo, con características adaptables a las
organizaciones y proyectos de software. Los productos de trabajo o elementos de modelo
que se elaboran durante el proceso se representan en UML. El proceso de RUP es iterativo
incremental, dirigido por requisitos o casos de uso, centrado en la arquitectura y enfocado a
la gestión del riesgo
1 1.3 Descripción de procesos actuales

Un proceso de desarrollo de software es el conjunto de actividades necesarias para
transformarlos requerimientos del usuario en un sistema informático". Un proceso define
quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo. Un sistema, por
pequeño que sea, generalmente es complicado. Por eso se necesita dividirlo empiezas si se
pretende comprenderlo y gestionar su complejidad. Esas piezas se pueden representar
través de modelos que permitan abstraer sus características esenciales. El modelado del
negocio es una técnica para comprenderlos procesos del negocio de la organización. Los
propósitos que se persiguen al realizarse el modelado del negocio son: entender la
estructura y la dinámica de la organización, entender los problemas actuales e identificar
mejoras potenciales, asegurarse de que los clientes, usuarios finales y desarrolladores
tengan una idea común de la organización y derivar los requerimientos del sistema a partir
del modelo de negocio que se obtenga. El modelo del negocio describe el negocio en
términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama
procesos. El modelo de casos de uso de las negociones un modelo que describe los procesos
de un negocio (casos de uso del negocio) y su interacción con elementos externos
(actores),1tales como socios y clientes, es decir, describe las funciones que el negocio
pretende realizar y su objetivo básico es describir cómo las negociones utilizado por sus
clientes y socios.
Proceso de software
La meta de la ingeniería de software es construir productos de software, o mejorar los

existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.
Un proceso de desarrollo de software es un conjunto de personas, estructuras de

organización, reglas, políticas, actividades y sus procedimientos, componentes de software,
metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar,
ofrecer un servicio, innovar y extender un producto de software.
Un proceso de software efectivo habilita a la organización a incrementar su productividad

al desarrollar software:
 Permite estandarizar esfuerzos, promover reuso, repetición y consistencia entre

proyectos.
 Provee la oportunidad de introducir mejores prácticas de la industria.
 Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
 Establece la base para una mayor consistencia y mejoras futuras.
Un proceso de software mejora los esfuerzos de mantenimiento y soporte:
 Define cómo manejar los cambios y liberaciones a sistemas de software existentes.

 Define cómo lograr la transición del software a la operación, y cómo ejecutar los
esfuerzos de operación y soporte.
1.2 Diagramas UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar
diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales
elementos. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a
las cuales se les conoce como modelo. Recordemos que un modelo es una representación
simplificada de la realidad; el modelo UML describe lo que supuestamente hará un sistema,
pero no dice cómo implementar dicho sistema. A continuación, se describirán los
diagramas más comunes del UML y los conceptos que representan:
 Diagrama de Clases
 Diagrama de Objetos
 Diagrama de Casos de Uso
 Diagrama de Estados
 Diagrama de Secuencias
Diagramas de clase
Dentro de los tipos de diagramas UML estructurales se encuentran los diagramas de clase.
Que representan las estructuras estáticas de un sistema, incluidas sus clases, atributos,
operaciones y objetos.
Diagramas de componentes
Los diagramas de componentes grafican de forma sencilla, cómo se combinan los

componentes del sistema, para formar componentes más grandes. En este tipo de diagramas
UML es posible comprender las dependencias dentro del proyecto.
Diagramas de implementación
Esto modelo, grafica la implementación física y la estructura de los componentes de

hardware. En estos diagramas se muestran dónde y cómo operarán los componentes del
sistema a desarrollar.
Diagramas de comportamiento
A diferencia de los diagramas estructurales, los de comportamiento, grafican la forma en

que se comporta un sistema de información de forma dinámica. Es decir, describe los
cambios que sufre un sistema a través del tiempo cuando está en ejecución, y se los conoce
como diagramas del tipo story board, o guion, lo que indica que muestra un
comportamiento en una línea temporal, es decir: qué sucede primero, que viene después,
etc.
1.3 Estudio de Factibilidad

Estudio de factibilidad
Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello
tomar la mejor decisión, si procede su estudio, desarrollo o implementación.
Objetivo de un Estudio de Factibilidad.
1.- Auxiliar a una organización a lograr sus objetivos.
2.- Cubrir las metas con los recursos actuales en las siguientes áreas.
a) Factibilidad Técnica.
 Mejora del sistema actual.

 Disponibilidad de tecnología que satisfaga las necesidades.
b) Factibilidad Económica.
 Tiempo del analista.

 Costo de estudio.
 Costo del tiempo del personal.
 Costo del tiempo.
 Costo del desarrollo / adquisición.
c) Factibilidad Operativa.
 Operación garantizada.
 Uso garantizado.
Referencias
Bonilla Huerta, E., Ramírez Cruz, F., & Sánchez Lucero , E. (2014). Advances in
Intelligent Information. LATINDEX, 17.
[Chalmeta, 1999]: Chalmeta R. “ADSI II. 2º Boletín de transparencias”. UJI, 1999.
[Davis A., 1995]: Davis A. 201 Principles of Software Development. 1ª ed. McGraw-Hill,
1995.

Tecnologico de Estudios Superiores de Valle de Bravo

Cargado por

Copyright:

Formatos disponibles

Tecnologico de Estudios Superiores de Valle de Bravo

Cargado por

Información del documento

Título original

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

Tecnologico de Estudios Superiores de Valle de Bravo

Cargado por

Copyright:

Formatos disponibles

OPCIÓN DE TITULACIÓN

TECNOLOGICO DE ESTUDIOS SUPERIORES DE VALLE DE BRAVO

INGENIERÍA EN SISTEMAS COMPUTACIONALES

ANDREA ADANALY SUÁREZ ESTRELLA

M.I.S.C. PRIMERO HUERTA CÉSAR

Los principales objetivos que se identifican en la especificación de requisitos software son:

Los principales objetivos que se identifican en la especificación de requisitos software son

1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

Existen 3 tipos de requisitos específicos :

Características de una buena ERS

El Proceso Unificado (UP), conocido comercialmente como RUP –Rational Unified

1 1.3 Descripción de procesos actuales

La meta de la ingeniería de software es construir productos de software, o mejorar los

Un proceso de desarrollo de software es un conjunto de personas, estructuras de

Un proceso de software efectivo habilita a la organización a incrementar su productividad

 Permite estandarizar esfuerzos, promover reuso, repetición y consistencia entre

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

 Define cómo manejar los cambios y liberaciones a sistemas de software existentes.

1.2 Diagramas UML

Los diagramas de componentes grafican de forma sencilla, cómo se combinan los

Esto modelo, grafica la implementación física y la estructura de los componentes de

A diferencia de los diagramas estructurales, los de comportamiento, grafican la forma en

1.3 Estudio de Factibilidad

Objetivo de un Estudio de Factibilidad.

1.- Auxiliar a una organización a lograr sus objetivos.

a) Factibilidad Técnica.

 Mejora del sistema actual.

 Tiempo del analista.

También podría gustarte