INTRODUCCIÓN ..............................................................................................................................................

4
I. CICLO DE VIDA DEL SOFTWARE ............................................................................................................. 5
1.1. PROCESOS DEL CICLO DE VIDA DE UN SOFTWARE ............................................................................. 6
1.2. PARADIGMAS ...................................................................................................................................... 7
1.2.1. Modelo Cascada. .......................................................................................................................... 7
1.2.2. Modelo en Espiral. ....................................................................................................................... 8

1.2.3. Modelo Iterativo o por Prototipos. .................................................................... 10

1.2.4. Modelo V o de Cuatro Niveles. .......................................................................... 11
1.2.5. Modelo Scrum. .................................................................................................... 12
1.2.6. Modelo Kanban. ................................................................................................. 13
II. FASE DE REQUERIMIENTOS. ..................................................................................... 13
2.1. Estándar IEEE 830-1998. ............................................................................................. 14
2.1.1. Las Características de un Buen ERS. ................................................................... 14
2.1.2. La Evolución de ERS. ........................................................................................... 17
2.1.3. Prototipos. .......................................................................................................... 17
2.1.4. Generando el Diseño en el ERS ................................................................................ 18
2.1.5. Requisitos del Proyecto en el ERS. ..................................................................... 18
2.1.6. La Perspectiva del Producto. .............................................................................. 19
2.1.7. Las Características del Usuario. .......................................................................... 19
2.1.8. Las Restricciones. ................................................................................................ 19
2.1.9. Prorrateando de Requisitos. .............................................................................. 20
2.1.10. Interfaces Externas. ............................................................................................ 21
2.1.11. Atributos del Software del Sistema. .................................................................. 22
2.2. Estándar IEEE 1063-2001 ............................................................................................ 23
2.2.1. ¿Qué es la Documentación? ............................................................................... 24
2.2.2. Recomendaciones para Escribir un Manual de Usuario .................................... 27
III. FASE DE ANÁLISIS Y DISEÑO ................................................................................ 27
3.1. Estándar IEEE 1471-2000. ........................................................................................... 27
3.1.1. Información General. .......................................................................................... 29
3.1.2. Propósito. ............................................................................................................ 30
3.1.3. Terminología. ...................................................................................................... 31
3.1.4. Conformidad. ...................................................................................................... 32
IV. ESQUEMA DEL CICLO DE VIDA DEL SOFTWARE ............................................ 33
V. CONCLUSIONES............................................................................................................. 34
VI. RECOMENDACIONES ............................................................................................... 35
VII. BIBLIOGRAFÍA O LINKOGRAFÍA ........................................................................... 36

DEDICATORIA.

Dedicamos este proyecto a Dios porque ha estado con nosotros a cada paso que
damos, cuidándonos y dándonos fortaleza para continuar, a nuestros padres los
cuales son pilares fundamentales y que a lo largo de nuestras vidas han velado
por nuestro bienestar y educación, siendo nuestros apoyos en todo momento,
depositando su entera confianza en cada reto que se nos presentaba, sin dudar
ni un solo momento en nuestra inteligencia y capacidad, es por ello que ahora
somos lo que somos; y a nuestro profesor porque desde el primer día de clases
nos ha demostrado, su apoyo, amabilidad, respeto, responsabilidad e interés por
brindarnos sus conocimientos de la mejor manera.
 AGRADECIMIENTO.

A Dios, por brindarnos la dicha de la salud, bienestar físico y espiritual, a nuestros

padres por su esfuerzo, amor y apoyo incondicional durante nuestra formación
tanto personal como profesional al mismo tiempo a los compañeros e integrantes
de este grupo que con gran interés y esfuerzo hemos logrado desarrollar este
trabajo de investigación.

A nuestro docente José Portilla Sampen, por brindarnos su guía y sabiduría en el

desarrollo de este trabajo.

Finalmente, un eterno agradecimiento a esta prestigiosa casa de estudios

“Universidad Politécnica Amazónica” la cual abre sus puertas a jóvenes como
nosotros, preparándonos para un futuro competitivo y formándonos como
personas de bien.
INTRODUCCIÓN

Los estándares de calidad de software hacen parte de la ingeniería de software,

utilización de estándares y metodologías para el diseño, programación, prueba y
análisis del software desarrollado, con el objetivo de ofrecer una mayor
confiabilidad, mantenibilidad en concordancia con los requisitos exigidos, con
esto se eleva la productividad y el control en la calidad de software, parte de la
gestión de la calidad se establecen a mejorar su eficacia y eficiencia.

En un escenario en el que los sistemas de software se desarrollan y construyen

por terceros proveedores, el contratante del servicio, como primer receptor del
mismo, en muchos casos debe confiar en el buen hacer del proveedor
seleccionado, especialmente si nos dispone de los medios apropiados para
auditar la entrega y en su caso argumentar defectos en el proceso de desarrollo.

En general, una vez validado que el sistema responde a los principales requisitos
funcionales especificados, el usuario realizará las pruebas de aceptación,
corrigiendo los errores encontrados y tas pasándose al fin del entorno de
producción. Sin embargo, en muy pocas ocasiones se validan de manera rigurosa
los requisitos funcionales y los no funcionales, o se ejecutan validaciones que
aseguren que el sistema es lo suficientemente robusto y estable como para pasar
a un entorno productivo con las garantías adecuadas.
I. CICLO DE VIDA DEL SOFTWARE
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), 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.

Es el proceso que se sigue para construir, entregar y hacer evolucionar el

software, desde la concepción de una idea hasta la entrega y retiro del sistema.
Se definen las distintas fases intermedias que se requieren para validar el
desarrollo de un software.

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.

Consta de 5 fases:
Figura 1 : ciclo de vida del software
 Fuente: Elaboración propia

1.1. PROCESOS DEL CICLO DE VIDA DE UN SOFTWARE

Los procesos principales del ciclo de vida son cinco, que dan servicio a las
partes principales durante el ciclo de vida del software. Una parte principal es
aquella que inicia o lleva a cabo el desarrollo, operación, o mantenimiento de
los productos software. Estas partes principales son el adquiriente, el
proveedor, el desarrollador, el operador y el responsable de mantenimiento
de productos software. Los procesos principales son:

Proceso de Adquisición.
Define las actividades del adquiriente, la organización que adquiere un sistema,
producto software o servicio software.

Proceso de Suministro.
Define las actividades del proveedor, organización que proporciona un sistema,
producto software o servicio software al adquiriente.

Proceso de Desarrollo.
Define las actividades del desarrollador, organización que define y desarrolla el
producto software.

Proceso de Operación.
Define las actividades del operador, organización que proporciona el
servicio de operar un sistema informático en su entorno real, para sus
usuarios.

Proceso de Mantenimiento.
Define las actividades del responsable de mantenimiento, organización
que proporciona el servicio de mantenimiento del producto software;
esto es, la gestión de las modificaciones al producto software para
mantenerlo actualizado y operativo. Este proceso incluye la migración y
retirada del producto software.
1.2. PARADIGMAS
Algunos paradigmas de desarrollo de software o modelos de proceso más relevantes
se definen a continuación:

1.2.1. Modelo Cascada.

El modelo de cascada es el modelo de paradigma más simple en desarrollo
de software. Sigue un modelo en que las fases del ciclo de vida del
software o ciclo de vida de desarrollo de software funcionarán una detrás
de la otra de forma lineal. Lo que significa que solamente cuando la
primera fase se termina se puede empezar con la segunda, y así
progresivamente. Este modelo asume que todo se lleva a cabo y tiene
lugar tal y como se había planeado en la fase anterior, y no es necesario
pensar en asuntos pasados que podrían surgir en la siguiente fase. Este
modelo no funcionará correctamente si se dejan asuntos de lado en la fase
previa. La naturaleza secuencial del modelo no permite volver atrás y
deshacer o volver a hacer acciones.

Este modelo es recomendable utilizar cuando el desarrollador ya ha

diseñado y desarrollado softwares similares con anterioridad, y por eso
está al tanto de todos sus dominios.

Figura 2: Modelo Cascada

Elaboración propia
1.2.2. Modelo en Espiral.
El modelo espiral en ingeniería del software tiene un enfoque muy distinto
al modelo de cascada, principalmente porque su enfoque va dirigido hacia
el análisis de riesgos. El modelo de ciclo de vida en espiral, consiste en
realizar diversas iteraciones, pasando por cada una de sus fases una y
otra vez. A diferencia de la modelo cascada que no tiene vuelta atrás, en
el modelo en espiral se pueden hacer las iteraciones que se consideren
necesarias y estas son sus fases principales:
Determinación de Objetivos.
Análisis de Riesgos.
Desarrollo y Pruebas.
Planificación.

Entre las principales ventajas de desarrollar un proyecto con el modelo

espiral, es que los riesgos se van disminuyendo conforme avanzan los
ciclos o iteraciones, de hecho, no puedes avanzar a un ciclo nuevo, si no
se ha dado solución a todos los riesgos latentes. Lamentablemente el
modelo es realmente costoso y para que puedas tener un alto nivel de
eficacia en la evaluación final de tu proyecto con este ciclo de vida,
necesitas que tu equipo tenga un gran nivel de conocimientos y si es
posible buena experiencia para superar cualquier riesgo al cual se puedan
enfrentar.
 Figura 3: Modelo Espiral

Evaluar alternativas
Determinar Objetivos, identificar y resolver
alternativas, restricciones riesgos

Acuerdo
REVISIÓN

Desarrollar, verificar

Planificar las próximas

fases

Elaboración propia
1.2.3.
Modelo Iterativo o por Prototipos.
Es uno de los primeros ciclos de vida que permitían que el código fuente
fuera reutilizable, sin embargo, con el modelo iterativo no solo es
utilizable, si no que, para muchos, estos prototipos pueden llegar a ser el
producto final que siempre quisieron, lo cual lo hace realmente relevante
y destacable, por encima del resto de los modelos de antaño que puedas
encontrar.

Básicamente, las fases del ciclo de vida del sistema, son las siguientes:
Inicialización.
Iteración.
Lista de Control.

Una de las principales ventajas del modelo iterativo, es que la

retroalimentación a los usuarios se proporciona desde muy temprano,
haciendo que adentrarse en el proyecto sea demasiado sencillo. Por
supuesto que el hecho de contar con iteraciones nos da ciertas ventajas,
pues con cada iteración realizada, se van separando las partes complejas
de él, permitiendo más el acceso al software. Y por supuesto, un sistema
creado mediante el ciclo de vida iterativo, tiende a no fallar casi, lo cual es
garantía de satisfacción para el cliente en este caso o para la empresa
que está implementando esta metodología.

Figura 4: Modelo Iterativo

Elaboración propia
1.2.4.

Modelo V o de Cuatro Niveles.

El modelo en V es una variación del modelo en cascada que muestra
cómo se relacionan las actividades de prueba con el análisis y el diseño.
Como se muestra en la Figura 3, la codificación forma el vértice de la V,
con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento
a la derecha.

La unión mediante líneas discontinuas entre las fases de la parte izquierda

y las pruebas de la derecha representa una doble información. Por un
lado, sirve para indicar en qué fase de desarrollo se deben definir las
pruebas correspondientes. Por otro sirve para saber a qué fase de
desarrollo hay que volver si se encuentran fallos en las pruebas
correspondientes.

Por lo tanto, el modelo en V hace más explícita parte de las iteraciones y

repeticiones de trabajo que están ocultas en el modelo en cascada.
Mientras el foco del modelo en cascada se sitúa en los documentos y
productos desarrollados, el modelo en V se centra en las actividades y la
corrección.

Figura 5: Modelo V
1.2.5.

Elaboración propia

Modelo Scrum.
El ciclo de vida del sistema, puede agilarse si se utiliza la metodología
Scrum, uno de los modelos del ciclo de vida del desarrollo del software
más populares y más recientes, bueno no tanto, pero si más que los de
antaño. El modelo Scrum, se encuentra basado en lo que es el desarrollo
incremental, es decir, conforme pasen las fases y las iteraciones, mayor
va a ser el tamaño del proyecto que se esté desarrollando, es por eso que
uno de los principales requisitos para llevarlo a cabo, es que tu equipo de
desarrollo sea de calidad. Teniendo una alta calidad en el equipo,
tendremos garantizado un excelente funcionamiento.

Como te mencionaba al principio, el modelo Scrum, deja de seguir

metodologías lineales, podemos despedirnos del modelo cascada y
secuencial, pues ahora procedemos a solapar las fases y no importará en
qué momento tengas que volver atrás, siempre habrá un equipo de trabajo
de buena calidad, que tenga ese soporte para aguantar los cambios que
son ciertamente normales dentro de la metodología Scrum. Por último,
como ingrediente vital tenemos la comunicación, y es que acá olvídate de
las tendencias de ese jefe que te tienen envuelto en una burbuja
desarrollando. Con el modelo scrum podrás estar comunicado con tu
1.2.6.
equipo de trabajo en todo momento, para estar al tanto de los sucesos.
Ahora veremos brevemente, cuáles son los procesos que el modelo Scrum
utiliza:

Product Backlog.
Sprint Backlog.
Sprint Planning Meeting.
Daily Scrum o Stand-up Meeting.
Sprint Review.
Sprint Retrospective.

Estas son las fases del ciclo de vida del software en esta metodología, el
cuál básicamente consiste en realizar un análisis de los requerimientos
del sistema (Product Backlog), señalar cuáles serán los objetivos a corto
o mediano plazo dentro de un sprint, ósea, la fase de desarrollo.
Posteriormente los desarrolladores harán lo suyo, se realizan algunas
pruebas y se retroalimenta de acuerdo a lo conseguido al terminar la
 última fase. Recuerda que aquí, se pueden añadir nuevas cosas en todo
momento, pues el modelo Scrum no se bloquea en ninguna de sus fases.

1.2.6. Modelo Kanban.

El modelo Kanban, es uno de los modelos más visuales de las
metodologías ágiles. Consiste en la creación de un tablero con etiquetas,
donde se seccionan cada una de las fases de su desarrollo, además se
clasifica de acuerdo a los equipos de trabajo y se les asignan objetivos a
corto, mediano y largo plazo.

Entre las ventajas de este modelo del ciclo de vida del software, destaca
el hecho de no tener un orden tal cual, de hecho, todas las fases
comienzan a trabajar a la par, no hay tiempos de espera y básicamente
su objetivo es que los desarrolladores y programadores estén trabajando
todo el tiempo. Si concluyes con las fases del proyecto que te
corresponde, seguramente tendrás que avanzar en fases del nuevo
proyecto que está por venir.

Por supuesto, la metodología Kanban, también requiere de un equipo

totalmente capacitado, pues solamente de esta forma se podrán lograr los
objetivos. Así que aquí les muestro las fases del proceso del ciclo de vida
de un sistema, mediante la metodología japonesa Kanban:

Definir el Flujo de Trabajo.

Fases del Ciclo de Producción.
Stop Starting, start finishing.
Tener un Control.

II. FASE DE REQUERIMIENTOS.

El análisis de requisitos es una de las tareas más importantes en el ciclo de vida
del desarrollo de software, puesto que en ella se determinan los “planos” de la
nueva aplicación.

El análisis de requisitos se puede definir como el proceso del estudio de las

necesidades de los usuarios para llegar a una definición de los requisitos del
sistema, hardware o software, así como el proceso de estudio y refinamiento de
dichos requisitos. Consta de dos estándares:
2.1. Estándar IEEE 830-1998.
El formato de Especificación de Requisitos Software (ERS) según la última
versión del estándar IEEE 830. Según IEEE, un buen Documento de
Requisitos, pese a no ser obligatorio que siga estrictamente la organización
y el formato dados en el estándar 830, sí deberá incluir, de una forma o de
otra, toda la información presentada en dicho estándar. El estándar de IEEE
830 no está libre de defectos ni de prejuicios, y por ello ha sido justamente
criticado por múltiples autores y desde múltiples puntos de vista, llegándose
a cuestionar incluso si es realmente un estándar en el sentido habitual que
tiene el termino en otras ingenierías.

2.1.1. Las Características de un Buen ERS. Un

ERS debe ser:

Correcto.
Un ERS es correcto si, y sólo si, cada requisito declarado se
encuentra en el software. No hay ninguna herramienta o
procedimiento que aseguran la exactitud. Alternativamente el
cliente o el usuario pueden determinar si el SRS refleja las
necesidades reales correctamente. Identificando los
requerimientos hace este procedimiento más fácil y hay menos
probabilidad al error.

Inequívoco.
Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene
sólo una interpretación. Como un mínimo, se requiere que cada
característica de la última versión del producto se describa usando
un único término. En casos dónde un término en un contexto
particular tenga significados múltiples, el término debe ser incluido
en un glosario dónde su significado es hecho más específico.
Completo.
Un SRS está completo si, y sólo si, incluye los elementos
siguientes:

a. Los requisitos están relacionados a la funcionalidad, el

desarrollo, las restricciones del diseño, los atributos y las
interfaces externas. En particular debe reconocerse
cualquier requisito externo impuesto por una especificación
del sistema y debe tratarse.

b. La definición de las respuestas del software a todos los

posibles datos de la entrada del sistema y a toda clase de
situaciones. Una nota que es importante especificar son las
contestaciones a las entradas válidas e inválidas a ciertos
valores.

c. Tener todas las etiquetas llenas y referencias a todas las

figuras, tablas, diagramas en el SRS y definición de todas
las condiciones y unidades de medida.

Consistente.
La consistencia se refiere a la consistencia interior. Si un SRS no
está de acuerdo con algún documento del superior-nivel, como una
especificación de requisitos de sistema, entonces no es correcto.

Delinear que tiene importancia y/o estabilidad.

Un SRS debe delinear la importancia y/o estabilidad si cada
requisito en él tiene un identificador para indicar la importancia o
estabilidad de ese requisito en particular. Típicamente, todos los
requisitos que relacionan a un producto del software no son
igualmente, importantes. Algunos requisitos pueden ser
esenciales, sobre todo para las aplicaciones de vida crítica,
mientras otros pueden ser deseables.

Comprobable.
Un SRS es comprobable si, y sólo si, cada requisito declarado es
comprobable. Un requisito es comprobable si, y sólo si, allí existe
algún proceso rentable finito con que una persona o la máquina
puede verificar que el producto del software reúne el requisito. En
general cualquier requisito ambiguo no es comprobable. Los
requisitos de No-verificable incluyen las declaraciones como
"trabaja bien", "interface humana buena" y "normalmente pasará"
no pueden verificarse los requisitos de esos porque es imposible
de definir las condiciones "bueno," "bien" o "normalmente". La
declaración que "el programa nunca entrará en una vuelta infinita"
es el no-verificable porque la comprobación de esta calidad es
teóricamente imposible.

Modificable.
Un SRS es modificable si, y sólo si, su estructura y estilo son tales
que puede hacerse cualquier cambio a los requisitos fácilmente,
completamente y de forma consistente mientras conserva la
estructura y estilo. Para que sea modificable se requiere un SRS
que contenga:

a. Tiene un coherente y fácil de usar en la organización de

volúmenes de información, un índice y las referencias
cruzadas explícitas.

b. No sea redundante (es decir, el mismo requisito no debe

aparecer en más de un lugar en el SRS);

c. Exprese cada requisito separadamente, en lugar de

intercalarlas con otros requisitos. La redundancia no es un
error, pero puede llevar fácilmente a los errores.

Identificable.
Un SRS es identificable si el origen de cada uno de sus requisitos
está claro y si facilita las referencias de cada requisito en el
desarrollo futuro o documentación del mismo. Lo siguiente que se
recomiendan dos tipos de identificabilidad:
 a. El identificable dirigido hacia atrás (es decir, a las fases
anteriores de desarrollo). Esto depende explícitamente en
cada requisito las referencias de su fuente en los
documentos más antiguos.

b. El identificable delantero (es decir, a todos los documentos

desovados por el ERS).

Esto depende en cada requisito en el ERS que tiene un único

nombre o número de la referencia.

2.1.2. La Evolución de ERS.

El ERS puede necesitar evolucionar, así como el desarrollo de las
actualizaciones del producto de software. Puede ser imposible de
especificar un poco a detalle en el momento que el proyecto se inicia (por
ejemplo, puede ser imposible de definir toda la estructura de la pantalla
para un programa interactivo durante la fase de requisitos). Los cambios
adicionales pueden suceder según como las deficiencias se vayan
descubriendo, las limitaciones e inexactitudes en el ERS.

Dos consideraciones en este proceso son las siguientes:

a. Deben especificarse los requisitos completamente como se es

conocido en el momento, aun cuando las revisiones evolutivas
pueden preverse como inevitable. El hecho que ellos están
incompletos debe ser anotado.

b. Un proceso de cambio formal debe comenzarse para identificarse,

el control, dejar huella e informe de lo que proyectaron los
cambios.

2.1.3. Prototipos.
Los prototipos frecuentemente se usan durante una fase de los requisitos
de un proyecto. Muchas herramientas existen para generar un prototipo
para exhibir algunas características de un sistema, ser creado muy
rápidamente y fácilmente.

Los prototipos son útiles por las razones siguientes:

a. El cliente puede ver el prototipo y reaccionar a él que leer el SRS

y reaccionar a él. Así, el prototipo proporciona la regeneración
rápida.

b. El prototipo despliega aspectos de anticiparse a la conducta de

los sistemas. Así, no sólo produce las respuestas sino también las
nuevas preguntas. Esto ayuda a ver el alcance en el SRS.

c. Un SRS basado en un prototipo tiende a sufrir menos cambios

durante el desarrollo, así se acorta el tiempo de desarrollo.

2.1.4. Generando el Diseño en el ERS

Un diseño describe un subcomponente particular de un sistema y/o sus
interfaces con otros subcomponentes. El diseñador del SRS debe
distinguir claramente entre identificar las restricciones del diseño
requeridos y proyectar un plan específico. La nota es que cada requisito
en el SRS limita las alternativas del plan. Esto no significa, sin embargo,
que cada requisito es el plan.

El SRS debe especificar qué funciones serán realizadas, con qué datos,
para producir qué resultados, en qué situación y para quien. El SRS se
debe enfocar en los servicios a ser realizados. El SRS normalmente no
debe especificar los puntos del plan como lo siguiente:

Partir el software en módulos

Asignando las funciones a los módulos
Describiendo el flujo de información o controles entre los módulos
Escogiendo las estructuras de los datos.

2.1.5. Requisitos del Proyecto en el ERS.

El SRS debe dirigir el producto del software, no el proceso de producir el
producto del software. Los requisitos del proyecto representan una
comprensión entre el cliente y el proveedor sobre materias contractuales
que pertenecen a la producción de software y así no deben ser incluidos
en el SRS. Éstos normalmente incluyen los puntos como:

El Costo
Los tiempos de la entrega
Informando los procedimientos
Los métodos de desarrollo de Software
La convicción de Calidad
La Aprobación y criterio de la comprobación Los
procedimientos de aceptación

2.1.6. La Perspectiva del Producto.

Esta subdivisión del ERS debe poner el producto en la perspectiva con
otros productos relacionados. Si el producto es independiente y
totalmente autónomo, debe declararse que así es. Si el ERS define un
producto que es un componente de un sistema más grande, como
frecuentemente ocurre, entonces esta subdivisión debe relacionar los
requisitos de ese sistema más grande a la funcionalidad del software y
debe identificar las interfaces entre ese sistema y el software.

Se recomienda utilizar diagramas de bloques que muestre los

componentes mayores del sistema más grande, las interconexiones, y las
interfaces externas pueden ser útiles.

2.1.7. Las Características del Usuario.

Esta subdivisión del ERS debe describir esas características generales de
los usuarios intencionales del producto que incluye nivel educativo,
experiencia, y la especialización técnica.

2.1.8. Las Restricciones.

Esta subdivisión del ERS debe proporcionar una descripción general de
cualquier otro punto que limitará las opciones de los diseñadores. Éstos
incluyen:

Políticas de la empresa
 Limitaciones del hardware
Interfaces con otras aplicaciones
Operaciones paralelas
Funciones de auditoría
Funciones de control
Lenguaje(s) de programación
Protocolos de comunicación (por ejemplo, XON-XOFF,
ACKNACK).

Requisitos de habilidad
Criticalidad de la aplicación
Consideraciones acerca de la seguridad

2.1.9. Prorrateando de Requisitos.

Esta subdivisión del SRS debe identificar requisitos:

Requisitos específicos
Esta sección del SRS debe contener todos los requisitos del
software a un nivel de detalle suficiente para permitirles a los
diseñadores diseñar un sistema para satisfacer esos requisitos, y
a los auditores a probar que el sistema satisface esos requisitos.
Esta es la parte más grande y más importante del SRS, los
principios siguientes aplican:

a. Deben declararse los requisitos específicos en la

conformidad con todas las características descritas.

b. Los requisitos específicos deben tener referencias

cruzadas a documentos más actuales que los relacionan.

c. Todos los requisitos deben ser

singularmente identificables.

d. Debe prestarse la atención debida a organizar los

requisitos para aumentar al máximo la legibilidad.

Requisitos del desarrollo.

 Esta subdivisión debe especificar los requerimientos estáticos y
dinámicos que se pusieron en el software o en la interacción
humana con el software en conjunto. Los requisitos estáticos
pueden incluir a lo siguiente:

a. El número de terminales a ser apoyadas

b. El número de usuarios simultáneos ser apoyados
c. La cantidad y tipo de información que se manejara.

A veces se identifican los requisitos estáticos bajo una sección

separada titulada la Capacidad. Por ejemplo, los requisitos
dinámicos pueden incluir los números de transacciones, tareas y
la cantidad de datos a ser procesado dentro de ciertos periodos
de tiempo para las condiciones del trabajo normales y máximas.

Requisitos del banco de datos lógicos.

Esto debe especificar los requisitos lógicos para cualquier
información que será puesta en un banco de datos. Esto puede
incluir a lo siguiente:

a. Los tipos de información usadas por varias funciones.

b. La frecuencia de uso.
c. Accediendo las capacidades.
d. Las entidades de los datos y sus relaciones.
e. Las restricciones de integridad.
f. Requerimientos en la retención de datos.

Restricciones del diseño.

Esto debe especificar las restricciones del diseño que pueden
imponerse por otros estándares, las limitaciones del hardware,
etc.

2.1.10. Interfaces Externas.

Ésta debe ser una descripción detallada de todas las entradas y salidas
del sistema del software. Debe complementar las descripciones de la
interfaz en 3.2 y no debe repetirse la información allí.

Debe incluir ambas entradas/salidas y debe estructurarse como sigue:

a. El nombre de artículo.
b. La descripción de propósito.
c. La fuente de entrada o destino de salida.
d. El rango válido, exactitud, y/o tolerancia.
e. Las unidades de medida.
f. Tiempos.
g. Las relaciones a otras entradas/salidas.
h. El formato de pantalla /organización.
i. El formato de ventanas/organización.
j. Los formatos de los datos.
k. Los formatos de los comandos.
l. Fin de mensajes.

2.1.11. Atributos del Software del Sistema.

Hay varios atributos del software que puede servir como los requisitos. Es
importante que los atributos se especifiquen para que su logro pueda
verificarse objetivamente.

Fiabilidad
Esto debe especificar que los factores exigieron establecer la
fiabilidad requerida del sistema del software al momento de la
entrega.

Disponibilidad
Esto debe especificar que los factores exigieron garantizar un
nivel de disponibilidad definido para el sistema como un punto de
control, la recuperación y al iniciar.
 Seguridad
Esto debe especificar los factores que protegen el software del
acceso accidental o malévolo, uso, modificación, destrucción o
descubrimiento. Los requisitos específicos en esta área podrían
incluir la necesidad a:

a. Utilice ciertas técnicas de encriptamiento.

b. Tenga Log de entrada o históricos de datos.
c. Asigne ciertas funciones a módulos diferentes.
d. Restrinja las comunicaciones entre algunas áreas del
programa.
e. La integridad de datos se verifique para variables críticas.

Mantenimiento
Esto debe especificar atributos de software que relaciona a la
facilidad de mantenimiento del propio software. Puede haber
algún requisito con toda seguridad de modularidad, interfaces, la
complejidad, etc. no deben ponerse los requisitos aquí.

Portabilidad
Esto debe especificar atributos de software que relaciona a la
facilidad de poner el software a otro servidor y/o sistemas
operativos. Esto puede incluir a lo siguiente:

a. Porcentaje de componentes con código cliente-servidor.

b. Porcentaje de código del cliente-servidor.
c. Uso de un idioma portátil probado.
d. Uso de un compilador particular o subconjunto de
lenguajes.

e. Uso de un sistema operativo particular.

2.2. Estándar IEEE 1063-2001

El estándar IEEE 1063-2001 brinda ese marco de referencia para establecer
qué partes deben conformar cualquier documento que deba ser utilizado por
un usuario del sistema o programa en cuestión.

Este estándar solo se aplica a la documentación de usuario, para la

documentación de carácter técnico se utilizan otras recomendaciones de las
cuales hablaremos en su momento. A grandes rasgos la recomendación del
IEEE establece las siguientes partes para un documento que usarán los
usuarios. Estas partes son:

Identificación de los datos (paquete, título).

Tabla de contenidos, en documentos con más de 8 páginas.
Lista de ilustraciones (optativo).
Introducción.
Información para el uso de la documentación.
Conceptos de las operaciones.
Procedimientos.
Información sobre los comandos de software.
Mensajes de error y resolución de problemas.
Glosario.
Referencias.
Características de navegación.
Índice o Índex.
Herramientas de búsqueda (en documentos electrónicos).

2.2.1. ¿Qué es la Documentación?

"Pensemos en nombres como los de Leonardo Da Vinci, Isaac Newton,
Galileo o algún otro. Todos sabemos que han hecho, pero, ¿Acaso
podríamos acordarnos de ellos si no tuviéramos registro de sus ideas o
de sus invenciones?"

En el caso de los grandes pensadores, mujeres y hombres, de la

humanidad su legado ha quedado plasmado en libros, esto es su obra y
pensamiento ha sido documentado.
La documentación tiene su fundamento en el método científico. Con la
intención de poder replicar el o los experimentos realizados para validar
alguna tesis, el científico registra todas las condiciones bajo las cuales se
realiza el experimento, de igual manera los resultados se escriben en
tablas y estas a su vez generan gráficos estadísticos que nos permiten
interpretarlos. En la actualidad los medios para llevar el registro de alguna
actividad son muy diversos, siendo los digitales los más utilizados en la
actualidad.

Ahora bien, definiremos a la documentación como el proceso de registrar

de manera ordenada los procedimientos y resultados obtenidos a lo largo
de una investigación científica o proyecto o en general cualquier actividad
que se necesite repetir más de una vez, por ejemplo: una receta de cocina
bien documentada deberá llevar el tiempo exacto de cocción y la
temperatura exacta en la que el platillo obtiene sus mejores propiedades.
Documentar nos permite dar el salto entre lo empírico y lo científico, entre
el azar y las mejores prácticas.
Documentar un sistema de información implica almacenar y organizar la
información necesaria (en forma de documento escrito o gráfico) con la
intención de que al terminar el proyecto podamos: mantenerlo, mejorarlo
y/o repetirlo. La cantidad de documentos generados a lo largo del proyecto
va a depender del equipo que construye el software y del o los marcos de
desarrollo que utilice la organización. Además, en el caso de proyectos
empresariales se deberá guardar documentación incluso de la
configuración del hardware donde se despliegan los sistemas construidos.

2.2.1.1. Documentación Administrativa.

Se refiere a los documentos que forman parte del contexto de la
administración del proyecto como tal: Planes de trabajo, Definición del
proyecto, Definición de roles y perfiles de los integrantes del proyecto.
Análisis de costos, Análisis de riesgos, etc. En este lugar, por ejemplo,
podríamos colocar todos los documentos de la gestión de proyectos
que establece el PMBOOK.
2.2.1.2. Documentación Técnica:
Desarrollo de software.
En este apartado pueden colocarse los documentos
relacionados con el ciclo de desarrollo del sistema. De igual
manera la cantidad de documentos varía de acuerdo al
framework utilizado para crear el producto de software. Un
marco más ágil como SCRUM, no consideraría tantos
documentos en su lugar consideraría más que suficiente que
el código se comente de acuerdo al estándar del lenguaje, por
ejemplo, en Java se deberá utilizar el formato JavaDoc.

Aplicativos utilizados.
En el caso de aplicaciones empresariales donde además de
desarrollar software a la medida se utilizan algunos
programas que ya son comercializados, debemos guardar la
memoria de instalación de los diversos aplicativos que forman
la plataforma.

Componentes de hardware
Se debe guardar registro de la configuración del hardware
sobre el cual se está instalando el aplicativo, debemos
recordar que lo que deseamos es replicar el proceso más
veces, por lo que la omisión de la configuración que tiene el
hardware puede ser crucial para obtener los resultados
esperados.

Procesos.
Tener escritos los procesos con base a estándares permitirá
a las empresas evaluarlos y mejorarlos. Los procesos del
cliente nos sirven para adecuar el producto de software a la
empresa. La empresa que desarrolla el software o que ofrece
 servicios de IT puede encontrar un gran apoyo en marcos de
referencia como ITIL.

Vamos a cerrar el tema considerando lo siguiente:

• La documentación permite repetir el ciclo de

desarrollo del software

• Permite la mejora continua

• Establece las bases del conocimiento del negocio
• Marca el estándar de calidad del software
• Permite medir el avance del proyecto
• Establece un legado para la siguiente generación de
desarrolladores

Finalmente considero que cualquier proyecto de software de

mediana a gran escala, que no esté bien documentado está
condenado al fracaso y al olvido. Por otro lado, no existe una
lista de documentos estándar, en todo caso la lista de
documentos depende de las metodologías y marcos de
referencia utilizados en su desarrollo y de las indicaciones del
personal directivo.

2.2.2. Recomendaciones para Escribir un Manual de Usuario El

proceso de creación de un manual de usuario es cosa sencilla siempre y
cuando se tenga en cuenta algunos puntos, los cuales deben seguirse en
secuencia para no perdernos.

El primer paso para escribir el manual sería: Identificar al usuario

de la documentación o ¿quiénes serán los lectores potenciales del
documento? Esto nos ayudará a ubicar cuál es el nivel técnico que
se deberá utilizar en el documento y de alguna manera a plantear
su contenido.
 El segundo paso será definir su tabla de contenidos. Necesitamos
saber qué información será colocada en él y en qué orden. Una
buena práctica es colocar la tabla de contenidos en una matriz, en
una hoja de cálculo, para ir señalando el avance de cada tema o
proceso y de esa manera conocer el avance de lo que vamos
escribiendo y su relación.

Tercero Organizar el contenido. Una pregunta recurrente es ¿qué

se debe colocar en un manual de usuario o cómo se debe
organizar? Bien yo utilizó dos aproximaciones: Colocar en el
índice los casos de uso y clasificarlos de acuerdo a los usuarios
que los utilizan u organizar la información por funcionalidad.

III. FASE DE ANÁLISIS Y DISEÑO

3.1. Estándar IEEE 1471-2000.

IEEE 1471 es el nombre corto para un estándar conocido formalmente como
ANSI / IEEE 1471-2000, éste estándar es recomendado para la descripción
de la arquitectura de Sistemas de Software Intensivo. Dentro del Instituto de
Ingenieros de Electrónica (IEEE), esta es una "práctica recomendada", la
menos normativa de sus normas. En 2007 esta norma fue adoptada por la
ISO / IEC JTC 1 / SC7 como ISO / IEC 42010: 2007, Sistemas e Ingeniería
de Software.

Desde hace tiempo se ha reconocido que la arquitectura tiene una fuerte

influencia sobre el ciclo de vida de un sistema. Sin embargo, hasta hace
relativamente poco, los problemas de hardware han tendido a dominar el
pensamiento arquitectónico, y los aspectos de software, cuando se
considera en absoluto, eran a menudo los primeros en ser comprometidos
bajo las presiones de desarrollo. IEEE 1471 fue creado para proporcionar
una base para pensar en la arquitectura de los sistemas intensivos en
software.
Tiene contribuciones que pueden resumirse de la siguiente manera:

Proporciona definiciones y un meta-modelo para la descripción de la

arquitectura.

Se establece que una arquitectura debe abordar las preocupaciones

de los Stakeholders de un sistema.

Se afirma que las descripciones de la arquitectura son inherentemente

multi-vista, sin vistas solo capta adecuadamente todas las
preocupaciones de los Stakeholders.

Se separa la noción de vista desde el punto de vista, donde el punto

de vista identifica el conjunto de las Stakeholders y las
representaciones / técnicas de modelado, etc. utilizado para describir
la arquitectura al hacer frente a los Stakeholders y un punto de vista
del resultado al aplicar un punto de vista de un sistema en particular.

Establece los requisitos de contenido de las descripciones de la

arquitectura y la idea de que una descripción de la arquitectura
conformada, tiene una correspondencia 1 a 1 entre sus puntos de
vista y sus opiniones.

Proporciona una guía para la captura de la arquitectura lógica y la

identificación de inconsistencias / problemas no resueltos entre los
puntos de vista dentro de una descripción de la arquitectura.

3.1.1. Información General.

El ambiente de un sistema o contexto, pueden influir en el sistema. El
ambiente puede incluir otros sistemas que interactúan con el sistema de
interés, ya sea directamente a través de interfaces o indirectamente de
otras maneras. El entorno determina los límites que definen el alcance del
sistema de interés en relación a otros sistemas.
Un sistema tiene uno o más grupos de interés. Cada parte interesada tiene
típicamente intereses en él, o preocupaciones con respecto a, ese
sistema.

Las preocupaciones son esos intereses que tienen que ver con el
desarrollo del sistema, su funcionamiento o cualesquiera otros aspectos
que son críticos o de otra manera importante a una o más partes
interesadas. Las preocupaciones incluyen consideraciones del sistema
tales como el rendimiento, la fiabilidad, la seguridad, la distribución y la
capacidad de evolución.

Existe un sistema para cumplir con una o más misiones en su entorno.

Una misión es un uso u operación que un sistema se pretende por una o
más partes interesadas para cumplir con un conjunto de objetivos. Cada
sistema tiene una arquitectura. Una arquitectura puede ser registrada por
una descripción de la arquitectura.

Una descripción arquitectónica se organiza en uno o más componentes

llamados puntos de vista (de arquitectura). Cada vista se dirige a una o
más de las preocupaciones de los actores del sistema. Una vista es una
expresión parcial de la arquitectura de un sistema con respecto a un punto
de vista particular.

Un punto de vista establece los convenios por los que se crea una vista,
representados y analizados. De esta manera, una vista se ajusta a un
punto de vista. El punto de vista determina los idiomas (incluyendo
anotaciones, modelo o tipo de producto) que se utilizan para describir la
vista, y los métodos de modelado asociados o técnicas de análisis que se
aplicarán a estas representaciones de la vista. Estos lenguajes y técnicas
se utilizan para producir resultados pertinentes a las preocupaciones
abordadas por el punto de vista.
Una descripción arquitectónica selecciona uno o más puntos de vista para
su uso. La selección de los puntos de vista se basa normalmente en la
consideración de los grupos de interés a los que se dirige la AD y sus
preocupaciones. Una definición de punto de vista puede tener su origen
con un AD, o puede haber sido definida en otro lugar (un punto de vista
de la biblioteca).

Una vista puede consistir en uno o más modelos de arquitectura. Cada

uno de esos modelos arquitectónicos se desarrolla utilizando los métodos
establecidos por su punto de vista arquitectónico asociado. Un modelo
arquitectónico puede participar en más de una vista.

3.1.2. Propósito.
Según IEEE 1471 una descripción de la arquitectura se puede usar para
lo siguiente:

Expresión del sistema y su evolución

La comunicación entre los actores del sistema.
Evaluación y comparación de las arquitecturas de una manera
consistente.

La planificación, la gestión y la ejecución de las actividades de

desarrollo del sistema.
La expresión de las características persistentes y apoyar los
principios de un sistema para guiar el cambio aceptable.

Verificación de cumplimiento de la implementación del sistema con

una descripción arquitectónica.

Grabación de contribuciones al cuerpo de conocimientos de

software de arquitectura de sistemas intensivos.

3.1.3. Terminología.
De acuerdo con el estándar IEEE el glosario de la Terminología de
Ingeniería de Software se utilizan las siguientes definiciones:
Arquitecto.
La persona, equipo u organización responsable del diseño de la
arquitectura de sistemas.

Descripción Arquitectónica (AD).

Una colección de productos para documentar una arquitectura.

Arquitectura.
La organización fundamental de un sistema encarnada en sus
componentes, sus relaciones entre sí y con el medio ambiente, y
los principios que guían su diseño y evolución.

El Diseño.
Las actividades a definir, documentar, mantener, mejorar y
certificar la correcta aplicación de una arquitectura.

Sistema.
Una colección de componentes organizada para llevar a cabo una
función específica o un conjunto de funciones. El sistema de
expresión abarca las aplicaciones individuales, los sistemas en el
sentido tradicional, subsistemas, sistemas de sistemas, líneas de
productos, familias de productos, empresas integrales y otras
agravaciones de interés.

Sistema de los Stakeholders.

Un individuo, equipo u organización (o clases de los mismos) con
intereses en, o preocupaciones en relación con, un sistema.

Vista.
Una representación de todo un sistema desde la perspectiva de
un conjunto relacionado de preocupaciones.

Punto de Vista.
 Una especificación de los convenios para la construcción y el uso
de una vista. Un patrón o plantilla desde la que se desarrollan
visitas individuales mediante el establecimiento de los objetivos y
la audiencia para una vista y las técnicas para su creación y
análisis.

3.1.4. Conformidad.
IEEE 1471 define un conjunto de requisitos normativos para las
descripciones de arquitectura conformes, que incluyen lo siguiente:

Identificación de AD, versión e información general.

Identificación de las partes interesadas del sistema y sus

inquietudes que se consideran relevantes para la arquitectura.

Especificaciones de cada punto de vista que se ha seleccionado

para organizar la representación de la arquitectura y la
justificación de esas selecciones.

Una o más vistas arquitectónicas.

Un registro de todas las inconsistencias conocidas entre los

componentes requeridos de la descripción arquitectónica.

Una justificación para la selección de la arquitectura.

IV. ESQUEMA DEL CICLO DE VIDA DEL SOFTWARE

V. CONCLUSIONES.
 El ciclo de vida de software consta de varias etapas, todas ellas
relacionadas entre sí, las cuales permiten el desarrollo de sistemas de
una forma más ordenada y con mejor control, obteniendo al final un
producto de calidad.

Gracias a las normas y estándares aplicados a proyectos TI y de calidad

para el desarrollo de software hoy en día se nos puede facilitar la
realización de los proyectos ya que con las normas podemos seguir
ciertos pasos para que los proyectos sean más eficientes y más fáciles
de realizarlos paso a paso y los estándares nos especifican que el
desarrollo de un proyecto debe ser de calidad, el cual debe satisfacer las
necesidades del cliente o de la empresa a la que se le esté desarrollando
dicho software.

La etapa de pruebas, es de vital importancia para certificar la calidad del

software, pero no hay que olvidar que la Calidad no depende solo de
dicha etapa, la calidad debe estar implícita desde el inicio del ciclo de
vida de software.

La aplicación de una norma o estándar los podemos aplicar en nuestros

proyectos de acuerdo a las necesidades de dicho proyecto.

VI. RECOMENDACIONES
No confundir el concepto de ciclo de vida de un software con la
metodología de desarrollo de software.

Tener bien claro cada proceso que comprende el ciclo de vida de un

proyecto software para que no se tenga ninguna dificultad al realizar
cada proceso.

Aprenderse bien que comprende cada fase del ciclo de vida del software.

Escoger el modelo de vida de software dependiendo los beneficios que

me va a otorgar escoger dicho modelo.
VII. BIBLIOGRAFÍA O LINKOGRAFÍA

https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf

https://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf

https://datenpdf.com/download/ieee-1471_pdf

https://chae201521701014974.wordpress.com/2015/11/10/estandar-ieee-1471-

2000/ https://es.scribd.com/document/322092689/Estandar-IEEE-Std-1063

https://es.scribd.com/document/256301174/IEEE-1471

https://okhosting.com/blog/el-ciclo-de-vida-del-software/#Modelo_en_el_Espiral

https://www.tutorialspoint.com/es/software_engineering/software_development_

life_cycle.htm