Ingeniera de Software

Proyecto exitoso
- Tiempo Estimado
- Presupuesto estimado
- Cumple con funcionalidad requerida
- Que se use
Si se cumplen los 3 primeros el proyecto/producto se considera exitoso de lo contrario es
deficiente
Por qu no son exitosos:
- Eleccin errnea de los stakeholders
- Deficiencias en las habilidades de los desarrollos
- Estimacin de esfuerzo y tiempo errneos
- Escaza gestin de la calidad del producto de software
- Seleccin de tecnologas errneas
- Otros
Ingeniera de software: Disciplina formada por herramientas, mtodos y tcncinas que se usan en
el desarrollo de software. Busca que el desarrollo de los proyectos sean efectivos (calidad) y
eficientes (costo). Tambin permite guiar de manera sistemtica todo el proceso de desarrollo de
software.
Software:
- Producto intangible que se compone de un conjunto de datos, programas, documentos y
configuraciones.
- Nos entrega informacin
- Masificacin de produccin y uso de software en los ltimos aos.
- No es posible medir los efectos culturales que tiene la masificacin del software.
- El software se desarrolla o se construye no se manufactura en el sentido clsico.
- El software no se desgasta, se deteriora debido a los cambios introducidos.
- La mayora se construye a medida.
Tipos de software:
- De Sistemas: Sistemas operativos, dentro de S.O. (winzip, etc)
- De aplicacin: gestin (bancos, gestin de clientes, hospital, supermercado, etc)
- De ingeniera y cientfico: Matlab, autocad.
- Empotrado (embedidos): microondas
- De lneas de producto: se van agregando y sacando cosas.
- Aplicacin web: Facebook, google drive.
- De IA: fundir cobre, maquinaria automatizada.


Mitos del desarrollo de software:
- Ya tengo un libro con procesos s todo.
- Atrasado, agregar ms gente
- Enunciados generales sin especificar sirven
- Los requerimientos cambian con facilidad, el software es flexible, cambiar es fcil.
- Cuando se termina de escribir un programa y est funcionando el trabajo est terminado.
Proyecto de Software
- Objetivos simples y cuando estos objetivos son acabados el proyecto est completo
(Divide y vencers)
- Plan de trabajo + Equipo de trabajo + estimacin de tiempo= Carta Gantt
Roles:
1. JP:
a. Liderazgo
b. Capacidad de comunicacin y trabajo en equipo.
c. Dominio del tema
d. Capacidad de gestin
e. Poder de decisin.
2. Stakeholder:
a. Participa o ha participado en los procesos que se quieran automatizar.
3. Analista: Anlisis del problema, entiende el problema y plantea posible solucin
4. Diseador: Soluciones tcnicas del problema
5. Constructor: Recibe las soluciones del diseador
6. Documentador: Documenta el proyecto, estndares a seguir, tiempos, etc.
7. QA: Asegura calidad del proyecto a lo largo del desarrollo, testers.
8. Arquitecto de software: Disea las tecnologas, un diseador senior.
9. DBA: Administra las BDD entre el diseador y constructor.










Etapas:
1. Especificacin de requisitos: es lo que tiene que hacer el software.
a. Entrevistas, reuniones, documentos, diagramas y revisiones.
2. Anlisis: Planteamos un problema y vemos una posible solucin para poder cumplir los
requisitos.
a. Identificar las necesidades del cliente.
b. Anlisis de la organizacin, como el entorno del sistema.
c. Modelar la solucin propuesta.
3. Diseo: plantear solucin en especificaciones tcnicas.
a. Reflejo del anlisis
b. Facilitar etapas futuras.
c. Debe ser documentado.
d. Relaciones.
e. Lenguaje de programacin, aplicaciones existentes, volumen de datos.
f. Estado actual de los datos (normalizacin, encriptacin, etc.)
g. Proyeccin de crecimiento
4. Construccin: Programar lo que da el diseador.
5. Pruebas.
6. Implantacin: Llevar el software ya construido y probado a las instalaciones del cliente.
7. Mantencin: Soporte, posibles correcciones, agregar nuevas funcionalidades, capacitar a
los usuarios del software.
Trazabilidad: Registro que lleva el documentador indica dnde las especificaciones de
requisitos se llevan en el anlisis, registro del desarrollo de software.
Metodologas de Desarrollo de Software
1. Cascada: Proceso de desarrollo secuencial, tambin denominando desarrollo lineal o
clsico.
a. Comunicacin: Inicio del proyecto, recopilacin de requisitos.
b. Planificacin: Estimacin, itinerario, seguimiento.
c. Modelado: Anlisis Diseo.
d. Construccin: Cdigo, pruebas.
e. Despliegue: Entrega, soporte.
- Ventajas:
o Muy utilizado para adaptaciones o mejoras de sistemas existentes.
o til cuando los requisitos estn fijos.
- Desventajas:
o Es raro que los proyectos reales sigan el flujo secuencial.
o Es difcil que el cliente sepa de manera explcita todos los requisitos.
o El cliente debe tener paciencia.
2. Incremental: Aplica secuencias del modelo de cascada de manera iterativa.
o El primer incremento corresponde al producto esencial
o El plan se va modificando al entregar cada incremento, para cubrir de mejor
manera las necesidades del cliente.
o Se entrega un producto operacional al finalizar cada iteracin.
o til cuando no se tiene todo el personal necesario para el desarrollo del proyecto.

I. Modelos Evolutivos.
1. Prototipo:
a. Se basa en la produccin de una versin operacional del software, para un
conjunto de requisitos limitado (excluyndose parte de la funcionabilidad)
b. Existen dos principales metodologas:
i. Prototipo Desechable
ii. Prototipo evolutivo.
o Ventajas:
Los usuarios tienen la posibilidad de interactuar con el prototipo y
realimentar a los desarrolladores.
Para los usuarios es ms confortable enfrentarse a un prototipo que a una
especificacin.
Decrece el esfuerzo de desarrollo entre un 40% y 70%. Un diseo rpido
es posible cuando los requisitos son claros.
o Desventajas:
Se puede adicionar funcionalidad intrascendente bajo presiones de uso
normal.
Posibilidad de pensar que es en s una especificacin (slo es parte).
Puede demostrar funcionalidad que no es posible bajo apremios reales.
El usuario puede creer que tiene frente a s el sistema completo y
operable.
Posibilidad de subestimar el proyecto, ya que las salidas estn pronto
disponibles.

2. Modelo Espiral: Se basa en un acercamiento orientado a la determinacin del
riesgo en la evolucin del software.
a. Planificacin
b. Anlisis de riesgo
c. Ingeniera
d. Evaluacin de cliente
o Ventajas:
Demanda una consideracin directa de los riesgos tcnicos en todas las
etapas del proyecto.
Permite la utilizacin de la creacin de prototipos como un mecanismo de
reduccin del riesgo.
Permite utilizar el enfoque de creacin de prototipos en cualquier etapa
de evolucin del producto.
o Desventajas:
Criticidad del anlisis de riesgo.
Difcil de vender como algo controlable.
Especificacin de Requisitos:
Proceso sistemtico de definicin, comprensin, anlisis y documentacin de los requisitos.
Los requisitos definen los servicios que el sistema debe proporcionar a los usuarios; y las
restricciones y condiciones de uso de los mismos.

Tipos de requisitos:
1. De carcter general, pueden ser vistos en trminos amplios como lo que el
sistema debe hacer.
2. Funcionales, definen las funcionalidades del sistema.
3. No funcionales, definen caractersticas del rendimiento y de la implementacin

Dado que los requisitos son de diversos tipos no es posible definir un nico procedimiento
estndar de especificacin de los mismos.

Principios para una buena especificacin:
La especificacin debe separar funcionalidad de implementacin.
La especificacin necesita utilizar un lenguaje de especificacin orientado a procesos.
La especificacin debe abarcar el entorno en el que opera el sistema.
La especificacin debe ser un modelo cognitivo.
La especificacin debe ser tolerable a la incompletitud y ampliable.
La especificacin debe ser localizada y dbilmente acoplada.

Problemas Comunes:
Muchos de los problemas que aparecen en los sistemas una vez en utilizacin se derivan
de problemas aparecidos, o no detectados, en la fase de anlisis y/o especificacin de los
requisitos.
Los requisitos no reflejan las necesidades reales del cliente del sistema.
Los requisitos son inconsistentes y/o incompletos.
Es difcil introducir cambios en los requisitos una vez que estos han sido consensuados
entre cliente y desarrollador.
Hay una falta de entendimiento entre clientes y aquellos que desarrollan el sistema.
Estructura de un Documento ERS
La estructura que establece el estndar IEEE/ANSI 830-1993 para el documento de
especificacin de requisitos es:
1. Introduccin
2. Descripcin general
3. Requisitos especficos
4. Apndices
5. Glosario


Requisitos no funcionales
Corresponden a los atributos o caractersticas de calidad que debe tener el software.
Estndar ISO 9126
o Se compone de cuatro partes: modelo de calidad, mtricas externas, mtricas
internas y mtricas para la calidad en uso.
o En la primera parte, se describen detalladamente seis caractersticas y sub-
caractersticas de calidad para los productos de software.
o Se puede determinar el grado de calidad de estos productos segn la evaluacin
de estas caractersticas y sub-caractersticas.
Caractersticas:
1. Funcionalidad:
a. Adecuacin: lo que realmente debe hacer, se comprueban con la trazabilidad.
b. Correccin: Pruebas.
c. Interoperabilidad:
d. Seguridad: acceso a la informacin, perfiles.
e. Conformidad: otros estndares.
2. Fiabilidad:
a. Madurez: Teniendo mismas condiciones de entrada va a responder de igual
forma
b. Tolerancia a fallos: Niveles de desempeo, que no se caiga.
c. Recuperabilidad: Si falla se puede recrear el estado anterior.
d. Conformidad: otros estndares.
3. Usabilidad:
a. Comprensibilidad: Comprender el software.
b. Aprendibilidad: Aprender sin manual.
c. Operabilidad: Como operamos el software
d. Atractividad: Diseo
e. Conformidad: otros estndares
4. Eficiencia:
a. Comportamiento temporal: tiempo de respuesta
b. Uso de recursos: Cuanta memoria, RAM, HDD, etc.
c. Conformidad: Otros estndares, tiempo de respuesta mnimo
5. Mantenibilidad:
a. Analizabilidad.
b. Comabiabilidad: Facilidad de cambios, depende de la trazabilidad.
c. Estabilidad: Versiones estables.
d. Facilidad de pruebas.
e. Conformidad: Estndares en la especificacin de requisitos.
6. Portabilidad:
a. Adaptabilidad: Distintos dispositivos.
b. Instalabilidad: Facilidad de instalar el software.
c. Co existencia: Con otro software
d. Reemplazabilidad: Si existe en el mercado un software que realice lo mismo