Qu es la Ingeniera de Software?

ciencia que principalmente se avocar al desarrollo del software

involucra la calidad de este en su resultado.
Qu es un proceso del software?
Un conjunto de actividades cuya meta es el desarrollo o evolucin del software.
paradigma
es una agrupacin de mtodos, herramientas y procedimientos con el fin de describir u modelo.
permite producir programas con una directriz especfica, tales como: estructura modular, fuerte cohesin, alta rentabilidadmodelo de proceso o paradigma de ingeniera del software
es la estrategia para el desarrollo que acompaa a procesos, mtodos y capas de herramientas.
Los mtodos
indican cmo construir de manera tcnica el Sw. Aqu es donde precisamente vemos el anlisis de requisitos, diseo, codificacin,
pruebas y mantenimiento.
Las herramientas
ofrece un soporte automtico o semi-automtico para el proceso y para los mtodos.
Paradigma en Ingeniera de Software.
Existen tres categoras de paradigmas de programacin:
1. Los que soportan tcnicas de programacin de bajo nivel (ejemplo: copia de ficheros frente estructuras de datos
compartidos).
2. Los que soportan mtodos de diseo de algoritmos (ejemplo: divide y vencers, programacin dinmica, etc.).
3. Los que soportan soluciones de programacin de alto nivel, como los descritos en el punto anterior.
Paradigma en Ingeniera de Software.
Mtodo (modelo) Lineal Secuencial o de Cascada (Waterfall).
Mtodo (modelo) Incremental.
Mtodo (modelo) en Espiral.
Mtodo (modelo) de Prototipos.
Mtodo (modelo) en V.
Modelo Unified Process.
ModeloTeam Software Process TSP
Paradigmas de Codificacin (programacin).
Estructurada.
Objetos.
Eventos.
El desarrollo de un sistema de software est enmarcado
por los recursos, el tiempo y un conjunto de requerimientos.

Para lograrlo debe existir una planeacin y un seguimiento a sta.

Una planeacin est conformada por
actividades, recursos y tiempo
Esas actividades se llevan a cabo
dentro de un proceso definido

Proceso de construccin de Software

El conjunto completo de actividades de ingeniera de software necesarias para transformar los requerimientos del usuario
en software. [Humphrey]

Implcita o Explcitamente todos los modelos de ciclo de vida cuentan por lo menos con las siguientes actividades
REQUERIMIENTOS DISEO -> IMPLEMENTACIN -> PRUEBAS -> MANTENIMIENTO
Mtodo (modelo) Lineal Secuencial o de Cascada (Waterfall).
El paradigma del ciclo de vida clsico para la ingeniera del software. enfoque sistemtico, secuencial

Ingeniera y anlisis del sistema : estableciendo los requerimientos de todos los elementos del sistema y luego asignado algn
subconjunto de estos requerimientos al software
Anlisis de los requerimientos del software: Los requerimientos tanto del sistema como del software se documentan y revisan
con el cliente. comprender el dominio de la informacin del software
Diseo:traduce los requerimientos en una representacin del software que pueda ser establecida de forma que obtenga la
calidad requerida antes de que comience la codificacin. Como los requerimientos, el diseo se documenta y forma parte de la
configuracin del software.
Codificacin: traducirse en una forma legible para la mquina
Prueba: Una vez que se ha generado el cdigo, comienza la prueba del programa. La prueba se enfoca sobre la lgica interna
del software, asegurando que todas las sentencias se han probado, y sobre las funciones externas, esto es, realizando pruebas
para asegurar que la entrada definida producir los resultados que realmente se requieren.
Mantenimiento: El software sufrir indudablemente cambios despus de que se entregue al cliente (una posible excepcin es
el software empotrado). Ejemplo cambio de sist oper, agregar algn dispositivo perifrico.
Mtodo (modelo) Incremental.
forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema.
til cuando no se cuenta con una dotacin de personal suficiente
en cada incremento se aade personal
El usuario se involucra ms.
Difcil de evaluar el coste total
Los errores en los requisitos se detectan tarde.
El resultado puede ser muy positivo.

Mtodo (modelo) en Espiral. El Modelo en Espiral es un modelo de proceso de software evolutivo que conjuga la naturaleza
iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Ideal para realizar
versiones incrementales de manera rpida, que no se basa en fases claramente definidas y separadas para crear un sistema. Se
divide en un nmero de actividades de marco de trabajo, tambin llamadas regiones de tareas, Cada una de las regiones Estn
compuestas por un conjunto de tareas del trabajo llamado conjunto de tareas. Las regiones que definen esas actividades
comprenden un conjunto de tareas del trabajo: ese conjunto s se debe adaptar a las caractersticas del proyecto en particular a
emprender

Mtodo (modelo) de Prototipos.

Un prototipo es una versin preliminar de un sistema de informacin con fines de demostracin o evaluacin.
Como se construye sistema por Prototipos:
Identificacin de Requerimientos.
Diseo Rpido.
Utilizar el Prototipo.
Revisar y Mejorar.
Es un mtodo menos formal de desarrollo.
El prototipeo es una tcnica para comprender las especificaciones.
Un prototipo puede ser eliminado.
Un prototipo puede llegar a ser parte del producto final.
Utiles cuando los requerimientos son cambiantes.
Cuando no se conoce bien la aplicacin.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnologa.
Cuando se requiere rapidez en el desarrollo.
construccin de modelos de prueba
Mtodo (modelo) en Componentes

Qu es un Proyecto?
es un esfuerzo temporal llevado a cabo con el fin de crear un producto o servicio nico con un conjunto de actividades
coordinadas y controladas con fecha de inicio y de terminacin incluyendo restricciones de tiempo, costos y recursos.
Las fases o procesos bsicos de un proyecto son Iniciacin, Planificacin, Ejecucin (implementacin), Monitoreo y Control y
Cierre.
Las diez reas del conocimiento mencionadas en el PMBOK son:
Gestin de la Integracin de Proyectos (Gestin de Plan de Proyectos),
Gestin del Alcance en Proyectos,
Gestin del Tiempo en Proyectos,
Gestin de la Calidad en Proyectos,
Gestin de Costos en Proyectos,
Gestin del Riesgo en Proyectos,
Gestin de Recursos Humanos en Proyectos,
Gestin de la Comunicacin en Proyectos,
Gestin de Adquisiciones, y
Gestin de Interesados
En que consiste un proyecto
Definicin; aqu se desarrolla lo que corresponde a Iniciacin.
Planeacin; en lo que corresponde a Planeacin.
Seguimiento; en lo que corresponde a Ejecucin (implementacin), Monitoreo y Control y Cierre.

Estructura de Divisin de Trabajo (EDT) o WBS

Cada tarea en una EDT contribuye al objetivo de entregar el material requerido a tiempo y bien hecho. Ella organiza y define el
alcance total del proyecto. Cada nivel descendiente representa una definicin crecientemente detallada del trabajo del proyecto. La
estructura de divisin del trabajo (EDT) se descompone en paquetes de trabajo
Paquete de Trabajo
Es el proceso necesario para subdividir los principales productos entregables del proyecto y el trabajo del proyecto en componentes
ms pequeos y ms fciles de gestionar.
es un entregable o componente de trabajo del proyecto que est ubicado en el ms bajo nivel de cada rama de la estructura de divisin
del trabajo. incluye las actividades e hitos del cronograma requeridos para completar el entregable o componente de trabajo.
Descomposicin
La descomposicin es la subdivisin de los productos entregables de un proyecto en componentes ms pequeos y fciles de manejar,
hasta que el trabajo y los productos entregables se definen al nivel del paquete de trabajo, generalmente implica las siguientes
actividades:
1. Identificar los productos entregables y el trabajo relacionado
2. Estructurar y organizar la EDT
3. Descomponer los niveles superiores de la EDT en componentes detallados de nivel inferior
4. Desarrollar y asignar cdigos de identificacin a los componentes de la EDT
5. Verificar que el grado de descomposicin del trabajo es necesario y suficiente.
6. La identificacin de los principales productos entregables del proyecto y el trabajo necesario para producir tales productos
entregables exige analizar el enunciado del alcance del proyecto detallado.
Estimacin de Tiempos
La estimacin del tiempo forma parte del proceso de Gestin del Tiempo de la Administracin de Proyectos.
Los procesos de Gestin del Tiempo del Proyecto incluyen lo siguiente:
Definicin de las Actividades: identifica las actividades especficas del cronograma que deben ser realizadas para
producir los diferentes productos entregables del proyecto.
Establecimiento de la Secuencia de las Actividades: identifica y documenta las dependencias entre las actividades del
cronograma.
Estimacin de Recursos de las Actividades: estima el tipo y las cantidades de recursos necesarios para realizar cada
actividad del cronograma.
Estimacin de la Duracin de las Actividades: estima la cantidad de perodos laborables que sern necesarios para
completar cada actividad del cronograma.
Desarrollo del Cronograma: analiza las secuencias de las actividades, la duracin de las actividades, los requisitos de
recursos y las restricciones del cronograma para crear el cronograma del proyecto.
Control del Cronograma: controla los cambios del cronograma del proyecto.
Estimacin de recursos y costes
permite al comprador establecer una aproximacin al coste total y plazos del desarrollo del sistema.
Factores que afectan a esta estimacin:
La complejidad del proyecto, cuantificando la misma en funcin de:
Nmero de mdulos y nivel de interrelacin entre los mismos.
Nmero y tipo de las interfaces externas con otros sistemas, programas o datos.
Grado de distribucin y heterogeneidad del entorno de implantacin.
Grado de sofisticacin de las herramientas de desarrollo.
Naturaleza de los algoritmos que se deben disear y programar.
Red de Actividades
Se llama as a la representacin grfica de la matriz de antecedentes, secuencias y tiempos, mediante ella es posible mostrar en
forma clara y comprensible la relacin, interrelacin, secuencias, etc., de las actividades a realizar as como el camino crtico.
Las actividades se representan mediante flechas las cuales indican el tiempo que se ocupar en su realizacin.
Estas flechas pueden ser rectas, curvas, quebradas, etc., segn las necesidades en el trazo de la red,
En algunos casos, al trazar la red, es necesario indicar la relacin de una actividad con otro u oras, para lo cual es necesario
dibujar flechas que indiquen dicha relacin; este tipo de flechas, al no representar consumo de tiempo y/o recursos, se dibujan en
forma punteada,
Lista de Riesgos
Hace mencin a todas las posibles situaciones que pueden perjudicar el proyecto
Describe los riesgos tcnicos, de recursos o del negocio implicados en el proyecto, y formula un plan con medidas preventivas y
correctivas para enfrentar cada uno. Se ordenan de acuerdo a la importancia de manera decreciente. Es un artefacto de RUP que

nos provee una visin de todos los riesgos conocidos en el proyecto, y sirve como entrada para la planificacin y evaluacin del
proyecto.
Objetivo
Aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos
para el proyecto.
Qu es un riesgo?
Es un evento o condicin que puede o no ocurrir que, si se produce, tiene un efecto positivo o negativo sobre al menos un objetivo
del proyecto.
Todo riesgo implica 2 cosas:
Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir.
Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas. Cuando se analizan los riesgos
es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo.
Para poder cuantificar las prdidas, los riesgos se clasifican de la siguiente manera:
Riesgos del Proyecto: amenazan al plan del proyecto. Si ocurren, probablemente la planificacin temporal del proyecto se retrasa y
los costos aumentan. Identifican los problemas potenciales de presupuesto, planificacin temporal, personal, recurso, cliente y
requisitos y su impacto en un proyecto de software.
Riesgos Tcnicos: amenazan la calidad y la planificacin temporal del software que hay que producir. Si ocurren, la
implementacin puede llegar a ser difcil o imposible. Identifican problemas potenciales de diseo, implementacin, de interfaz,
verificacin y de mantenimiento. Ocurren porque el problema es ms difcil de resolver de lo que pensbamos.
Riesgos del Negocio: amenazan la viabilidad del software a construir. Los candidatos para los cinco principales riesgos del
negocio son:
Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado). Construir un producto que no
encaja en la estrategia comercial general de la compaa (riesgo estratgico). Construir un producto que el departamento de
ventas no sabe cmo vender (riesgo de ventas).
Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin).
Perder presupuesto o personal asignado (riesgos de presupuesto).
Lista de Riesgos
Cmo identificar los riesgos?
Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de riesgo. Se puede utilizar para identificar
riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras:
Tamao del producto
Impacto en el negocio
Caractersticas del cliente
Definicin del proceso
Entorno de desarrollo
Tecnologa a construir
Tamao y experiencia de la plantilla
Cmo tratar los riesgos?
Todas las actividades de anlisis de riesgo tienen un objetivo nico: ayudar al equipo del proyecto a desarrollar una estrategia
para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos:
Evitar el riesgo
Supervisar el riesgo
Gestin del riesgo y planes de contingencia
Identificacin de riesgos.

Fase de Elaboracin y Riesgos

Estimar los riesgos, las fuentes de incertidumbre.
Lista de riesgos y plan de contingencia
Plan de manejo de riesgos