INSTITUTO TECNOLOGICO SUPERIOR ESCÁRCEGA

Organismo Público Descentralizado de la Administración

Pública del Estado de Campeche

“Reporte de instalación de apache”

Materia:

Planificación y modelado

Alumno:

Olivera Sosa Ángel Gabriel

Profesor:

Carolina Novelo Can

Semestre:

VII semestre

Ingeniería en sistemas computacionales

Escárcega, Campeche, a 06 de septiembre 2010.

 Requerimientos de procesos
requerimientos de procesos son la especificación de los estándares de
calidad que se deben utilizar en el proceso, una especificación que el diseño
debe producir con una herramienta CASE particular y una descripción del
proceso a seguir.

Requerimientos funcionales

Requerimientos funcionales. Son declaraciones de los servicios que

debe proporcionar el sistema, de la manera en que éste debe reaccionar a
entradas particulares y de cómo se debe comportar en situaciones particulares.
En algunos casos, los requerimientos funcionales de los sistemas también
pueden declarar explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen lo que el

sistema debe hacer. Estos requerimientos dependen del tipo de software que
se desarrolle, de los posibles usuarios del software y del enfoque general
tomado por la organización al redactar requerimientos. Cuando se expresan
como requerimientos del usuario, habitualmente se describen de una forma
bastante abstracta. Sin embargo. los requerimientos funcionales del sistema
describen con detalle la función de éste, sus entradas y salidas, excepciones,
etcétera. Los requerimientos funcionales para un sistema software se pueden
ex.presar de diferentes formas. A continuación se presentan algunos ejemplos
de estos requerimientos funcionales para un sistema de biblioteca universitario,
denominado LIBSYS, utilizado por estudiantes y personal docente que solicitan
libros y documentos de otras bibliotecas.

1. El usuario deberá tener la posibilidad de buscar en el conjunto

inicial de la base de datos o seleccionar un subconjunto de ella.
2. El sistema deberá proporcionar visores adecuados para que el
usuario lea documentos en el almacén de documentos.
3. A cada pedido se le deberá asignar un identificador único
(ID_PEDIDO), que el usuario podrá copiar al área de
almacenamiento permanente de la cuenta.

Estos requerimientos funcionales del usuario definen los recursos específicos

que el sistema debe proporcionar. Dichos requerimientos se toman del
documento de requerimientos del usuario, e ilustran los diferentes niveles de
detalle en que se pueden redactar los requerimientos funcionales (contraste los
requerimientos l y 3). El sistema LIBSYS es una interfaz única para diferentes
bases de datos de artículos. Esto permite a los usuarios descargar copias de
artículos publicados en revistas. periódicos y publicaciones científicas. Una
descripción más detallada de los requerimientos para el sistema en el cual se
basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniería de
requerimientos (Kontonya y Sommerville, 1998). La impresión en la
especificación de requerimientos es la causa de muchos de los problemas de la
ingeniería del software. Para un desarrollador de sistema"! 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
deben establecer nuevos requerimientos y hacer cambios en el sistema. Por
supuesto. esto retrasa la entrega de éste e incrementa los costes.

En principio, la especificación de requerimientos funcionales de un sistema

debe estar completa y ser consistente. La completitud significa que todos los
servicios solicitados por el usuario deben estar definidos. La consistencia
significa que los requerimientos no deben tener definiciones contradictorias. En
la práctica, para sistemas grandes y complejos, es prácticamente imposible
alcanzar los requerimientos de consistencia y completitud. Una razón de esto
es que es fácil cometer errores y omisiones cuando se redactan
especificaciones para sistemas grandes y complejos. Otra razón es que los
stakeholders del sistema (véase el Capítulo 7) tienen necesidades diferentes, y
a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando
los requerimientos se especifican por primera vez, por lo que se incluyen
requerimientos contradictorios en la especificación. Es posible que los
problemas surjan solamente después de un análisis más profundo.

Requerimientos no funcionales
Requerimientos no funcionales. Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el
proceso de desarrollo y estándares. Los requerimientos no funcionales a
menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican
a características o servicios individuales del sistema.

Los requerimientos no funcionales, como su nombre sugiere, son

aquellos requerimientos que no se refieren directamente a las funciones
específicas que proporciona el sistema, sino a las propiedades emergentes de
éste como la fiabilidad, el tiempo de respuesta y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema
como la capacidad de los dispositivos de entrada/salida y las representaciones
de datos que se utilizan en las interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con

características particulares del sistema. Más bien, estos requerimientos
especifican o restringen las propiedades emergentes del sistema. como se
explicó en el Capítulo 2. Por lo tanto, pueden especificar el rendimiento del
sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto
significa que a menudo son más críticos que los requerimientos funcionales
particulares. Los usuarios del sistema normalmente pueden encontrar formas
de trabajar alrededor de una función del sistema que realmente no cumple sus
necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional
puede significar que el sistema entero sea inutilizable.

Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de

fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema
de control de tiempo real no cumple sus requerimientos de rendimiento, las
funciones de control no funcionarán correctamente. Los requerimientos no
funcionales no sólo se refieren al sistema software a desarrollar. Algunos de
estos requerimientos pueden restringir el proceso que se debe utilizar para
desarrollar el sistema. Ejemplos de requerimientos de procesos son la
especificación de los estándares de calidad que se deben utilizar en el proceso,
una especificación que el diseño debe producir con una herramienta CASE
particular y una descripción del proceso a seguir.

Los requerimientos no funcionales surgen de las necesidades 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 software o
hardware, o a factores externos como regulaciones de segu

1. Requerimientos del producto. Estos requerimientos especifican el

comportamiento del producto. Algunos ejemplos son los
requerimientos de rendimiento en la rapidez de ejecución del
sistema y cuánta memoria se requiere; los requerimientos de
fiabilidad que fijan la tasa de fallos para que el sistema sea
aceptable; los requerimientos de portabilidad, y los requerimientos
de usabilidad.
2. Requerimientos organizacionales. Estos requerimientos se
derivan de políticas y procedimientos existentes en la
organización del cliente y en la del desarrollador. Algunos
ejemplos son los estándares en los procesos que deben utilizarse;
los 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.
3. Requerimientos externos. Este gran apartado incluye todos los
requerimientos que se derivan de los factores externos al sistema
y de su proceso de desarrollo. Éstos pueden incluir los
requerimientos de interoperabilidad que definen la manera en que
el sistema interactúa con sistemas de otras organizaciones; los
requerimientos legislativos que deben seguirse para asegurar que
el sistema funcione dentro de la ley. y los requerimientos éticos.
Estos últimos son puestos en un sistema para asegurar que será
aceptado por sus usuarios y por el público en general.
 Estudios de viabilidad

Para todos los sistemas nuevos, el proceso de ingeniería de

requerimientos debería empezar con un estudio de viabilidad. La entrada de
éste es un conjunto de requerimientos de negocio preliminares, una descripción
resumida del sistema y de cómo éste pretende contribuir a los procesos del
negocio. Los resultados del estudio de viabilidad deberían ser un informe que
recomiende si merece o no la pena seguir con la ingeniería de requerimientos y
el proceso de desarrollo del sistema.

1. Un estudiode viabilidad es unestudio corto y orientado a

resolvervarias cuestiones:
2. ¿Contribuye el sistema a los objetivos generales de la
organización?
3. ¿Se puede implementar el sistema utilizando la tecnología actual
y dentro de las restricciones de coste y tiempo?
4. ¿Puede integrarse el sistemacon otrossistemas existentes en la
organización?

La cuestión de si el sistema contribuye a los objetivos del negocio es

crítica. Si no contribuye a estos objetivos, entonces no tiene un valor real en el
negocio. Aunque esto pueda parecerobvio, muchas organizaciones desarrollan
sistemas que no contribuyen a sus objetivos porque no tienen una clara
declaración de estos objetivos, porque no consiguen definir los requerimientos
del negocio para el sistema o porque otros factores políticos u organizacionales
influyen en la creación del sistema. Aunque no se trata explícitamente, un
estudio de viabilidad debería ser parte de la fase de Inicio del Proceso
Unificado de Rationa

Llevar a cabo un estudio de viabilidad comprende la evaluación y

recopilación de la información, y la redacción de informes. La fase de
evaluación de la información identifica la información requerida para contestar
las tres preguntas anteriores. Una vez que dicha información se ha
identificado,se debería hablar con las fuentes de información para descubrir las
respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son:

1. ¿Cómose las arreglaría la organización si no se implementara

este sistema?
2. ¿Cuálesson los problemas con los procesos actuales y cómo
ayudaría unsistemanuevo
3. a aliviarlos?
4. ¿Cuál es la contribución directa que hará el sistema a los
objetivos y requerimientos del negocio?
5. ¿La información se puede obtener y transferir a otros sistemas de
la organización?
6. ¿Requiere el sistema tecnología que no se ha utilizado
previamente en la organización?
7. ¿A qué debe ayudar el sistema y a qué no necesita ayudar"
 En un estudio de viabilidad, se pueden consultar las fuentes de
información, como los jefes de los departamentos donde se utilizará el sistema,
los ingenieros de software que están familiarizados con el tipo de sistema
propuesto, los expertos en tecnología y los usuarios finales del sistema.
Normalmente. se debería intentar completar un estudio de viabilidad en dos o
tres semanas. Una vez que se tiene la información, se redacta el informe del
estudio de viabilidad. Debería hacerse una recomendación sobre si debe
continuar o no el desarrollo del sistema. En el informe, se pueden proponer
cambios en el alcance, el presupuesto y la confección de agendas del sistema
y sugerir requerimientos adicionales de alto nivel para éste.
 Portabilidad
La portabilidad (en inglés porting) es uno de los conceptos clave en la
programación de alto nivel.

Se define como la característica que posee un software para ejecutarse

en diferentes plataformas, el código fuente del software es capaz de reutilizarse
en vez de crearse un nuevo código cuando el software pasa de una plataforma
a otra. A mayor portabilidad menor es la dependencia del software con
respecto a la plataforma.

El prerrequisito para la portabilidad es la abstracción generalizada entre

la aplicación lógica y las interfaces del sistema. Cuando un software se puede
compilar en diversas plataformas (x86, IA64, amd64, etc.), se dice que es
multiplataforma. Esta característica es importante para el desarrollo de
reducción costos, cuando se quiere hacer una misma aplicación.

En algunos casos el software es "independiente" de la plataforma y

puede ejecutarse en plataformas diversas sin necesidad de ser compilado
específicamente para cada una de ellas, a este tipo de software se le llama
interpretado, donde un "intérprete" traduce (propiamente interpreta) las
instrucciones a tiempo de ejecución para que sean entendidas por diferentes
plataformas.