EXAMEN

Sistemas crticos
Son aquellos sistemas en los que un fallo pueda representar perdidas
econmicas significativas dao fsico o en el peor de los casos amenazas a
la vida humana
1. Sistema critico de negocios
Son aquellos sistemas que cuyos fallos pueden ocasionar grandes perdida
econmicas para el negocio que utiliza este sistema.
2. Sistemas crticos de misin
Sistemas crticos cuyo fallo no permite que se logre realizar una actividad
concreta.
3. Sistema crtico con parada segura
Son aquellos sistemas en los cuales en caso de presentarse un fallo el
sistema se detiene y entra en un estado seguro parar poder corregir el fallo
4. Sistema crtico con degradacin aceptable
Son aquellos sistemas en los cuales pueden presentarse fallos en algn
modulo pero el sistema sigue funcionando.
5. Sistema critico best efort
Son aquellos sistemas que hacen todo lo posible porque no all fallos (hacen
su mayor esfuerzo) pero no garantizan que no los haya

Requerimientos
Son aquellas funciones que el sistema a desarrollar debe cumplir
1. Requerimientos funcionales
Se refiere a las funciones que el sistema debe realizar
2. Requerimientos no funcionales
Se refiere a las caractersticas que el sistema debe tener (servicio fiabilidad
rendimiento)

 Procesos de software
Proceso de software clsico: MODELO CASCADA
Este proceso ordena rigurosamente las etapas para el desarrollo de
software
La siguiente fase no debe comenzarse hasta que la fase anterior
haya finalizado
Est dividido en 5 pasos

1. Ailis y definicin de requerimientos : Se analizan cuales sern

los objetivos que el software debe cubrir al finalizar el proceso
2. Diseo del sistema : se descompone y organiza el sistema en
elementos n que puedan desarrollas por separado aprovechando las
ventajas del desarrollo en equipo
3. Diseo del Programa : Es la fase donde se realizan los algoritmos
necesarios para el cumplimiento de los requerimientos del usuario
4. Codificacin: Es la fase donde se implementa el cdigo fuente
haciendo uso de prototipos as como pruebas y ensayos para corregir
errores.
5. Pruebas : Los elementos ya programados se ensamblan para
componer el sistema y se comprueba que funciona correctamente y
que cumple con los requisitos
6. Verificacin: Es la fase en la que el usuario final ejecuta el sistema
7. Mantenimiento : El software puede sufrir cambios despus de ser
entregado esta pasa debido a que puedan encontrarse nuevos
errores o que el sistema tenga que adaptarse a cambios de entorno
externo o debido a que el cliente quiera agregar o quitar cosas al
sistema .

Modelo evolutivo
Modelo en espiral:

El software se desarrolla en una serie de

versiones incrementales, durante las primeras iteraciones la versin
incremental podra ser un modelo en papel o un prototipo y durante las
ltimas iteraciones se producen versiones cada vez ms completas
Se divide por lo general en 6 regiones de tareas:
1.
2.
3.
4.
5.

6.

Comunicacin con el cliente:

Se requiere para establecer

comunicacin entre el desarrollado y el cliente.
Planificacin: Se requiere para definir recursos el tiempo y otra
informacin relacionada con el proyecto
Anlisis de riesgos: sirve para evaluar riesgos tcnicos y de
gestin
Ingeniera: se usa para construir una o ms representaciones d
la aplicacin.
Construccin y accin : en esta tarea se construye, prueba,
instala y se proporciona soporte al usuario (documentacin y
practica)
Evaluacin del cliente: tarea en la que se obtiene la
reaccin del cliente segn la evaluacin de las representaciones de
software creadas durante la etapa de ingeniera e implementada
durante la etapa de instalacin.

Cada una de las regiones esta compuesta por un conjunto de tareas de

trabajo. Para proyectos pequeos es nmero de tareas de trabajo y su
formalidad es baja, para proyectos mayores y ms crticos cada regin de
tareas contiene tareas de trabajo que se definen para lograr un nivel ms
alto de formalidad.
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de
software a gran escala debido a que el software va evolucionando a medida
que se va desarrollando se puede reaccionar mejor ante posibles riesgos.

MODELO INCREMENTAL
La propuesta del modelo es disear sistemas que puedan
entregarse por piezas
En una visin genrica, el proceso se divide en 4 partes:

Anlisis
Diseo
Cdigo
Prueba

Caractersticas:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios

con cierta frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo

inicial, ya que se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la
entrega temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada
realimentado, reduciendo sus desventajas slo al mbito de cada
incremento.

Resulta ms sencillo acomodar cambios al acotar el tamao de los

incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de

tiempo real, de alto nivel de seguridad, de procesamiento distribuido
y/o de alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto

Bajo este modelo se entrega software por partes funcionales ms pequeas

pero reutilizables llamadas incrementos, cada incremento se construye
sobre aquel que ya fue entregado

DRA: Desarrollo rpido de

aplicaciones
Tambin conocido como RAD (Rapid Application development)
Es un modelo para desarrollo de software lineal secuencial que enfatiza un
ciclo de desarrollo extremadamente corto. DRA es un proceso de alta
velocidad en el que se logra desarrollo rpido utilizando in enfoque de
construccin basado en componentes. El proceso DRA permite al equipo de
desarrollo crear un sistema completamente funcional dentro de periodos
cortos de tiempo.
Las faces DRA son las siguientes:

Modelado de gestin: las funciones de gestin se modelan de

forma que se pueda responder las siguientes preguntas: Qu
informacin conduce el proceso de gestin?, qu informacin se
genera? Quin la genera ?a dnde va la informacin ? Quin la
proceso?
Modelado de datos: aqu se definen las caractersticas (llamadas
atributos ) de cada uno de los objetos y las relaciones entre los
objetos .
Modelado de proceso: Las descripciones del proceso se crean
para aadir modificar suprimir o recuperar un objeto de datos. Es la
comunicacin entre objetos
Generacin de aplicaciones : en lugar de crear software con
lenguajes de programacin de tercera generacin DRA trabaja para
volver a utilizar componentes de programas ya existentes (cuando es
posible) o crear componentes reutilizables cunado es necesario
Pruebas de entrega: Como el proceso DRA enfatiza en la
reutilizacin ya se han comprobado muchos de los componentes de
los programas, esto reduce tiempo de pruebas. Sin embargo se

deben probar todos los componentes nuevos y se debe ejercitar todas

las interfaces a fondo.

Metodologas agiles
o XP (eXtreme Programming)
Es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo.
QU ES PROGRAMACIN EXTREMA O XP?

Metodologa liviana de desarrollo de software

Conjunto de prcticas y reglas empleadas para desarrollar software
Basada en diferentes ideas acerca de cmo enfrentar ambientes muy
cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y disear para el futuro distante, hacer
todo esto un poco cada vez, a travs de todo el proceso de desarrollo

OBJETIVOS.

Establecer las mejores prcticas de Ingeniera de Software en los

desarrollo de proyectos.
Mejorar la productividad de los proyectos.
Garantizar la Calidad del Software desarrollando, haciendo que este
supere las expectativas del cliente.

CONTEXTO XP

Cliente bien definido

Los requisitos pueden (y van a) cambiar

Grupo pequeo y muy integrado (mximo 12 personas

Equipo con formacin elevada y capacidad de aprender
CARACTERSTICAS XP
Metodologa basada en prueba y error
Fundamentada en Valores y Prcticas
Expresada en forma de 12 PrcticasConjunto completoSe soportan
unas a otrasSon conocidas desde hace tiempo. La novedad es
juntarlas

VALORES XP
Simplicidad XP propone el principio de hacer la cosa ms simple que
pueda funcionar, en relacin al proceso y la codificacin. Es mejor
hacer hoy algo simple, que hacerlo complicado y probablemente
nunca usarlo maana.
Comunicacin Algunos problemas en los proyectos tienen origen en
que alguien no dijo algo importante en algn momento. XP hace casi
imposible la falta de comunicacin.
Realimentacin Retroalimentacin concreta y frecuente del cliente,
del equipo y de los usuarios finales da una mayor oportunidad de
dirigir el esfuerzo eficientemente.
Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si
funcionamejralo)
EL ESTILO XP

Est orientada hacia quien produce y usa el software

Reduce el costo del cambio en todas las etapas del ciclo de vida del
sistema.
Combina las mejores prcticas para desarrollar software, y las lleva al
extremo.

Ventajas:

Programacin organizada.
Menos errores.
Satisfaccin del programador.

Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

o Scrum(eficacia+rapidez+versa
tilidad)
Es una metodologa gil para la gestin de proyectos, Su principal objetivo
es obtener resultados (normalmente prototipos) cuanto antes y adaptarse a
los cambios (normalmente, los cambios en los requisitos).
Los pilares de Scrum son, principalmente, dos: el ciclo de vida iterativo
e incremental y diversas reuniones a lo largo del proyecto.
El segundo pilar ms importante de Scrum son las reuniones (el
primero era el ciclo de vida iterativo e incremental, los Sprints). Su
importancia reside en que las reuniones son la base para lograr
transparencia y comunicacin, y posibilitan algo caracterstico en un equipo
gil: que sea auto-gestionado y multifuncional. Las reuniones se
realizan a lo largo de todo el proyecto, segn las siguientes tipologas:
Reunin de Planificacin del Sprint (Sprint Planning Meeting). Al
principio de cada Sprint, para decidir que se va a realizar en ese Sprint.
Reunin diaria (Daily Scrum). Mximo 15 minutos, en la que se trata
que hizo ayer, que va a hacer hoy y que problemas se han encontrado.
Reunin de Revisin del Sprint (Sprint Review Meeting). Al final de
cada Sprint, y se trata qu ha completado y qu no. Tambin se muestra el
trabajo al Product Owner.
Retrospectiva del Sprint (Sprint Retrospective). Tambin al final del
Sprint, y sirve para que los implicados den sus impresiones sobre el Sprint, y
se utiliza para la mejora del proceso.

o Las metodologas Crystal: Una

familia de metodologas giles
segn sea tu proyecto.
En las metodologas Crystal, proyectos grandes, que necesitan ms
coordinacin y comunicacin, se asocian con colores ms oscuros. Proyectos
en los que un fallo pueda causar mayores problemas, tambin se asocian
con colores ms oscuros.
As, aparece una familia de metodologas:

Clear, para equipos de hasta 8 personas o menos.

Amarillo, de entre 10 y 20 personas.
Naranja, para equipos entre 20 y 50 personas.
Roja, entre 50 y 100 personas.
etc.

A ms personas en el proyecto, ms coordinacin. A ms criticidad en el

software, ms rigurosidad en el proceso. El factor ms determinante en
cualquier caso, la comunicacin entre los participantes en el proyecto.

Las 7 propiedades de las metodologas Crystal

1 Entregas frecuentes, en base a un ciclo de vida iterativo e
incremental. Puede haber desde entregas semanales hasta trimestrales.
2 Mejora reflexiva. Las iteraciones ayudan a ir ajustando el proyecto, a
ir mejorndolo.

3 Comunicacin osmtica. Que el equipo est en una misma ubicacin

fsica, para lograr la comunicacin cara a cara.
4 Seguridad personal. Todo el mundo puede expresar su opinin sin
miedos, tenindosele en cuenta, considerndose su opinin, etc.
5- Enfoque. Perodos de no interrupcin al equipo (2h horas), objetivos y
prioridades claros, definiendo as tareas concretas.
6 Fcil acceso a usuarios expertos. Las Crystal (a diferencia de otras
como XP) no exigen que los usuarios estn continuamente junto al equipo
de proyecto as que, como mnimo, semanalmente debe haber reuniones y
los usuarios deben estar accesibles.

Gestin de proyectos

Gestin de proyectos
La gestin de proyectos es una parte esencial de la ingeniera del software.

Concepto: La gestin de proyectos es la disciplina del planteamiento

la organizacin la motivacin y el control de los recursos con el propsito de
alcanzar uno o vario objetivos.
El primer desafo de la gestin de proyectos es obtener o alcanzar la meta
del proyecto y el objetivo dentro de las limitaciones conocidas que son
alcance, tiempo, calidad y presupuesto
Las actividades principales de la gestin de proyectos son:

Redaccin de propuesta.
Planificacin, calendarizacin del proyecto.
Estimacin de costes del proyecto.
Supervisin y revisin de proyectos
Seleccin y evaluacin del personal
Redaccin y presentacin de informes

Administrador de proyectos
Es la persona que tiene la responsabilidad total de planteamiento y la
ejecucin acertada de cualquier proyecto.

El administrador de proyecto debe de poseer una serie de habilidades

inclusive una gran capacidad inquisitiva para detectar problemas en el
equipo y situaciones interpersonales.
Un buen gerente de proyecto puede reducir los riesgos significativamente
con ayuda de una poltica de comunicacin abierta asegurndose de que
cada participante significativo tenga oportunidad de expresar sus opiniones
y preocupaciones.
Es el responsable de tomar las decisiones para reducir riesgos al lmite cada
decisin tomada por el administrador de proyecto debe involucrar un
beneficio directo hacia el proyecto

Ing. Requerimientos
Procesos de ingeniera de requerimientos
El proceso se cumple en cinco fases: viabilidad, captura y
anlisis, especificacin, validacin y gestin de requisitos.
Estudio de viabilidad: Este permitir rendir un informe tanto al equipo de
desarrollo del proyecto como al usuario o cliente, donde se verificar si el
proyecto vale la pena desarrollarlo. Es de vital importancia para la
satisfaccin de los objetivos del negocio.
Captura y Anlisis: En esta fase el desarrollador o su equipo de desarrollo
entran en contacto con el usuario final o con el cliente para determinar el
alcance del proyecto o del sistema que se desea construir, adems, se debe
identificar cules son los servicios que prestar el sistema, su rendimiento,
sus necesidades y restricciones, y cules son los objetivos esperados.
Especificacin: Aqu se debe obtener un documento de especificacin de
requisitos, en cual se llega a definir de una forma completa, precisa y
verificable cada uno de los requerimientos o necesidades que debe
satisfacer el sistema a desarrollar, adems de sus respectivas restricciones
(software, hardware).

Validacin: Consiste en mostrar o comprobar que cada uno de los

requisitos obtenidos definen el sistema o proyecto que se va a construir y
que desea el cliente. En esta etapa solamente entran aquellos requisitos
que se mencionaron ya en la especificacin.
Gestin: Se realiza la comprensin y control de los cambios de cada una de
los requisitos, sean estos requisitos estables (corresponden al estado del
sistema) o voltiles (representan eventos que hacen que el sistema realice
una funcin dada).

La ingeniera de requerimientos es un proceso que comprende todas las

actividades para crear y mantener los requerimientos de un sistema.

Comprende cuatro actividades de alto nivel:

Estudio de factibilidad
Un estudio de factibilidad es a corto plazo y orientado a resolver si el
sistema:
o
o
o

Contribuye a los objetivos de la organizacin.

Se puede implementar con tecnologa actual dentro de
costo y tiempo.
Puede integrarse a otros existentes en la organizacin.

Obtencin y anlisis de requerimientos

Proceso difcil:
o Los interesados a menudo slo conocen lo que
desean en trminos muy generales.
o Los interesados expresan los requerimientos con
sus propios trminos y con un conocimiento
implcito de su propio trabajo.
o Diferentes interesados tienen requerimientos
distintos y los expresan de varias formas.
o Influencia de factores polticos.

o El entorno es dinmico, la importancia de los

requerimientos puede cambiar, nuevos
requerimientos pueden surgir.
Actividades del proceso:
o
o
o
o
o
o
o

Comprensin del dominio

Recoleccin de requerimientos
Clasificacin
Resolucin de conflictos
Priorizacin
Verificacin (completos, consistente y acordes)
Proceso iterativo con retroalimentacin continua
de cada actividad a las otras.

Tcnicas:
o Orientada a puntos de vista
o Escenarios
o Etnografa

Obtencin orientada a puntos de vista

Toma en cuenta la existencia de varias perspectivas y provee de un
marco de trabajo para descubrir conflictos.
Un "punto de vista" puede significar:
o Una fuente o consumidor de datos
o Un marco de trabajo de la representacin (un tipo de
modelo)
o Un receptor de servicios

 Validacin de requerimientos
o Similar al anlisis pero comprende un bosquejo
completo del documento en lugar de
requerimientos incompletos.
o Importante pues los errores en los
requerimientos pueden conducir a costos
excesivos si se descubren durante el desarrollo o
despus de la implantacin
o Es difcil demostrar que un conjunto de
requerimientos cumple con las necesidades del
usuario.
Se deben llevar a cabo diferentes tipos de
verificacin:
o
o
o
o
o

Verificacin de
Verificacin de
Verificacin de
Verificacin de
Verificabilidad

validez
consistencia
integridad
realismo

Administracin de requerimientos
Los requerimientos de sistemas grandes son siempre
cambiantes.
Los sistemas grandes usualmente se desarrollan para
mejorar el status
Surgirn nuevos requerimientos debido a:

o Comunidad de usuarios diversa. Los

requerimientos finales son comnmente un
trmino medio.
o Quien paga es raramente quien usa el sistema.
o Entorno de negocios y tcnico cambiante.

La administracin de requerimientos es el proceso de

comprender y controlar los cambios en los
requerimientos.
La planeacin comienza al mismo tiempo que la
obtencin inicial de requerimientos.
La administracin activa debe iniciar tan pronto est
lista la primera versin del documento de
requerimientos.
La administracin de requerimientos incluye la gestin de la
planeacin, en la cual se especifican las polticas y
procedimientos para la administracin de los
requerimientos, y la del cambio, en la que se analizan los
cambios y se evala su impacto.

Sistemas socio tcnicos

Los sistemas socio-tcnicos incluyen hardware, software y personas
(operadores de los procedimientos y procesos) y se sitan dentro de
una organizacin. Estn diseados para ayudar a la compaa a

cumplir algn objetivo amplio por ejemplo televisiones telfonos

mviles

Sistemas socio-informticos
Son aquellos sistemas que contienen componentes de hardware y
software pero no procedimientos y procesos

Propiedades emergentes
Existen dos tipos de propiedades emergentes:
Las propiedades emergentes funcionales aparecen cuando
todas las partes de un sistema trabajan de forma conjunta para
cumplir algn objetivo. Por ejemplo, una bicicleta tiene la
propiedad funcional de ser un instrumento de transporte una vez
que sus componentes se han conjuntado.
Las propiedades emergentes no funcionales
Las propiedades emergentes no funcionales se refieren al
comportamiento de los sistemas en su entorno operativo. Ejemplos
de propiedades no funcionales son la fiabilidad, el rendimiento, la
seguridad y la proteccin.