Professional Documents
Culture Documents
Público
Este tutorial está diseñado para lectores interesados en aprender a
dominar y desarrollar Software, futuros profesionales para Pruebas de
programas y por supuesto para todos los lectores entusiastas.
Requisitos previos
Este tutorial está diseñado y desarrollado para principiantes. No
obstante, un conocimiento previo sobre sistemas de software y su
proceso de desarrollo, así como algunas nociones informáticas básicas
sería beneficioso.
Definiciones
El IEEE (Instituto de Ingeniería Eléctrica y Electrónica) define la
Ingeniería de software como:
(1) La aplicación de una aproximación sistemática, disciplinada y cuantificable,
al desarrollo, las operaciones y al mantenimiento del software; Esto es
básicamente la aplicación de la Ingeniería al software.
Paradigmas de Software
Los paradigmas de Software son métodos y pasos, que se llevan a
cabo mientras el software se diseña. Hay muchos métodos que se han
propuesto y que funcionan hoy en día, pero necesitamos ver donde se
ubican estos paradigmas en el marco de la Ingeniería de software.
Estos se pueden combinar en varias categorías, en las que cada uno
de ellos contiene a la otra:
El paradigma de programación es una parte del paradigma de diseño
de Software y más adelante también se considera parte del paradigma
de desarrollo de Software.
• Recogida de requisitos
• Diseño de Software
• Programación
• Diseño
• Mantenimiento
• Programación
Paradigma de programación
Este paradigma se relaciona de estrechamente a aspectos de
programación en el desarrollo de software. Esto incluye –
• Codificación
• Pruebas
• Integración
Necesidad de la Ingeniería de
Software
La necesidad de la Ingeniería de software viene de la alta tasa de
cambio en los requisitos y en el entorno en que trabaja el software.
• Transicional
• Mantenimiento
Operacional
Esto nos cuenta lo bien que funciona el software en operaciones. Se
puede medir en base a:
• Presupuesto
• Usabilidad
• Eficiencia
• Exactitud
• Funcionalidad
• Confiabilidad
• Seguridad informática
• Seguridad
Transicional
Este aspecto es importante cuando el software se mueve de una
plataforma a la otra:
• Portabilidad
• Interoperabilidad
• Reutilización
• Adaptabilidad
Mantenimiento
Estos aspectos resumen la capacidad que tiene el software para
mantenerse en entornos contantemente cambiantes:
• Modularidad
• Sostenibilidad
• Flexibilidad
• Escalabilidad
En resumen, La Ingeniería de Software es una rama de las ciencias de
la computación, que usa conceptos de Ingeniería bien definidos
requeridos para producir productos software eficientes, duraderos,
escalable, y asequibles a tiempo.
Recolección de solicitudes
A partir de este paso y en adelante el equipo de desarrollo software
trabaja para tirar adelante el proyecto. El equipo se reúne con varios
depositarios de dominio del problema, e intentan conseguir la máxima
cantidad de información posible sobre lo que requieren. Los requisitos
se contemplan y agrupan en requisitos del usuario, requisitos
funcionales y requisitos del sistema. La recolección de todos los
requisitos se lleva a cabo como se especifica a continuación -
• Estudiando el software y el sistema actual u obsoleto,
Estudio de viabilidad
Después de la recolección de requisitos, el equipo idea un plan para
procesar el software. En esta fase, el equipo analiza si el software
puede hacerse para cubrir todos los requisitos del usuario y si hay
alguna posibilidad de que el software ya no sea necesario. Se investiga
si el proyecto es viable a nivel financiero, práctico, y a nivel
tecnológico para que la organización acepte la oferta. Hay varios
algoritmos disponibles, los cuales ayudan a los desarrolladores a
concluir si el proyecto software es factible o no.
Diseño de Software
El siguiente paso es diseñar el producto software con la ayuda de toda
la información recogida sobre requisitos y análisis. Los inputs
(aportaciones) de los usuarios y los resultados de la recogida de
información hecha en la fase anterior serán las aportaciones base de
la fase actual. El output (o resultado) de esta etapa toma la forma de
2 diseños; El diseño lógico y el diseño físico. Los ingenieros crean
meta-data (Metadatos), Diagramas dilógicos, diagramas de flujo de
datos, y en algunos casos pseudocódigos.
Codificación
Esta fase también se puede denominar 'fase de programación'. La
implementación del diseño de software empieza con el lenguaje de
programación más conveniente, y desarrollando programas
ejecutables y sin errores de manera eficiente.
Pruebas
Se estima que el 50% de todos los procesos de desarrollo de software
deberían ser evaluados. Los errores pueden arruinar el software tanto
a nivel crítico y hasta el punto de ser eliminado. Las pruebas de
Software se hacen mientras se codifica y suelen hacerlo los
desarrolladores y otros expertos evaluadores a varios niveles. Esto
incluye evaluación de módulos, evaluación del programa, evaluación
del producto, evaluación interna y finalmente evaluación con el
consumidor final. Encontrar errores y su remedio a tiempo es la llave
para conseguir un software fiable.
Integración
El Software puede necesitar estar integrado con las bibliotecas, Bases
de datos o con otro u otros programas. Esta fase del SDLC se focaliza
en la integración del software con las entidades del mundo exterior.
Implementación
Aquí se instala el software en máquinas de clientes. A veces, el
software necesita instalar configuraciones para el consumidor final con
posterioridad. El Software se evalúa por su adaptabilidad y su
portabilidad, en cuanto a las cuestiones relacionadas con la
integración y conceptos asociados, se resuelven durante la
implementación.
Mantenimiento y Funcionamiento
Esta fase confirma el funcionamiento del software en términos de más
eficiencia y menos errores. Si se requiere, los usuarios se forman, o
se les presta documentación sobre como operar y como mantenerlo
en funcionamiento. El software se mantiene de forma temprana
actualizando el código en acorde a los cambios que tienen lugar en
entornos del usuario o tecnológicos. Esta fase puede que tenga que
encarar retos originados por virus ocultos o problemas no identificados
del mundo real.
Disposición
Con el paso del tiempo, puede que el software falle en su ejecución.
Puede que se vuelva totalmente obsoleto o que necesite
actualizaciones. De ahí surge una necesidad urgente de eliminar una
parte importante del sistema. Esta fase incluye archivar datos y
componentes software requeridos, cierre del sistema, planificación de
la actividad de disposición y terminación de sistema en el momento
final del sistema.
Modelo de 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 SDLC
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.
Modelo repetitivo
Este modelo guía el proceso de desarrollo de software en repeticiones.
Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso
después de cada ciclo en el proceso de SDLC.
Modelo en espiral
El modelo en espiral es una combinación de ambos modelos, el
repetitivo y uno del modelo SDLC. Se puede ver como si se combina
un modelo de SDLC combinado con un proceso cíclico (modelo
repetitivo).
Este modelo considera el riesgo, factor que otros modelos olvidan o
no prestan atención en el proceso. El modelo empieza determinando
los objetivos y las limitaciones del software al inicio de cada repetición.
En la siguiente etapa se crean los modelos de prototipo del software.
Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC
se usa para construir el software. En la cuarta etapa es donde se
prepara el plan de la siguiente repetición.
Modelo V
El mayor inconveniente del modelo de cascada es que solo se pasa a
la siguiente fase cuando se completa la anterior, por tanto no es
posible volver atrás si se encuentra algún error en las etapas
posteriores. El Modelo V aporta opciones de evaluación del software
en cada etapa de manera inversa.
• Creación Software
Proyecto Software
Un proyecto software es todo el procedimiento del desarrollo de
software, desde la recogida de requisitos, pasando por las pruebas y
el mantenimiento, y llevado a cabo en acorde a las metodologías de
ejecución, en un momento concreto en el tiempo para lograr el
producto software deseado.
• Definir el alcance
• Verificar el alcance
La suma del tiempo requerido para completar todas las tareas en horas
o días es el tiempo total que se invierte para terminar el proyecto.
Este debe de ser considerado como el más difícil de todos porque depende
de más elementos que los anteriormente mencionados. Para estimar el
coste de un proyecto, se requiere considerar -
o El Hardware
o Implicaciones de viaje
o Comunicación
o Formación y soporte
Técnica de descomposición
Esta técnica toma el software como un producto de varias
composiciones.
• Modelo Putnam
• COCOMO
• Calcular el tiempo total requerido des del inicio hasta el final del
proyecto
Gestión de recursos
Todos los elementos usados para desarrollar el producto software se
pueden tomar como recursos para ese proyecto. Esto puede incluir
recursos humanos, herramientas productivas y bibliotecas software.
• Cierre - Al final de cada evento mayor, de cada fase del SDLC o del
proyecto mismo, se anuncia el cierre administrativo para actualizar a
cada accionista vía email, o distribuyendo una copia por escrito del
documento o a través de otro medio de comunicación efectivo.
Gestión de la configuración
La gestión de la configuración es un proceso de seguimiento y control
de cambios en el software en términos de requisitos, diseño, funciones
y desarrollo del producto.
Línea de Base
Una fase del SDLC se considera completa si se hace la línea base de
este, esto es, la línea de base es una medida que define el fin de una
fase. La fase se completa cuando todas las actividades pertenecientes
a ésta se han terminado y documentado satisfactoriamente. S no fuera
la fase final, su resultado u output se usaría en la siguiente fase.
Control de cambios
El control de cambios es una función de gestión de la configuración, la
cual asegura que todos los cambios realizados al sistema software son
consistentes y se han hecho siguiendo regulaciones y normas de
organización.
Gráfico Gantt
Los gráficos Gantt fueron concebidos por Henry Gantt (1917).
Representan la temporalización del proyecto respecto a los periodos
de tiempo. Es un gráfico de barras horizontal que representa las
actividades y la temporalización para éstas en el proyecto.
Gráfico PERT
El diagrama PERT (Técnicas de Revisión y & Evaluación de Proyectos)
es una herramienta que representa el proyecto como un diagrama de
red. Es capaz de representar de forma gráfica eventos principales del
proyecto de forma paralela y consecutiva. Los eventos, que se dan
uno tras otro, muestran dependencia con el evento más reciente por
encima del previo.
Los eventos se muestran en número de nódulos. Se conectan con
flechas etiquetadas representando la secuencia de tareas en el
proyecto.
Histograma de recursos
Es una herramienta gráfica que contiene un esquema representando
el número de recursos (normalmente personal formado) requeridos
conforme avanza el tiempo para el evento de un proyecto o fase. El
histograma de recursos es una herramienta efectiva para el personal
de planificación y de coordinación.
Análisis de la ruta crítica o del camino crítico
Esta herramienta es útil para reconocer tareas interdependientes en
el proyecto. También contribuye a encontrar el camino más corto para
completar el proyecto con éxito. Como los diagramas PERT, a cada
evento se le adjudica un marco temporal. Esta herramienta muestra
dependencia de evento asumiendo que un evento puede proceder al
siguiente solamente si el previo a éste se ha completado.
Ingeniería de requisitos
El proceso de recogida de información, análisis y documentación sobre
los requisitos software des del cliente, se conoce como ingeniería de
requisitos.
• Estudio de viabilidad
• Recogida de requisitos
Estudio de viabilidad
Cuando el cliente se acerca a la organización para obtener el producto
deseado desarrollado, expone una idea aproximada de las funciones
que el software debe cumplir y qué características se esperan del
software.
Recogida de requisitos
Si el informe de viabilidad es positivo en relación a tomar el proyecto,
la siguiente fase empieza con la recolección de requisitos por parte del
consumidor. Analistas e Ingenieros se comunican con el cliente y los
consumidores para conocer sus ideas sobre qué debe aportar el
software y qué características quieren que incluya éste.
• Si se han completado
• Si se pueden demostrar
Entrevistas
Las entrevistas son medios de recogida de requisitos medianamente
fuertes. La organización puede conducir muchos tipos de entrevistas,
tales como:
• Entrevistas orales
Encuestas
La organización puede conducir encuestas o sondeos entre varios
accionistas pidiendo sus expectativas y requisitos para el sistema que
se va a desarrollar.
Cuestionarios
Un documento con preguntas objetivas definidas previamente con sus
opciones respectivas. Se entrega a todos los accionistas para que las
respondan, se recogen y se recopilan.
Una limitación de esta técnica es que, si una opción por algún asunto
no se menciona en el cuestionario, el asunto puede quedar
desatendido.
Análisis de tareas
El equipo de ingenieros y de desarrolladores puede analizar la
operación por la cual se requiere el nuevo sistema. Si el cliente ya
tiene algún software para realizar ciertas operaciones, se estudia y los
requisitos del sistema propuesto se recogen.
Análisis de dominio
Cada software pertenece a una categoría de dominio. Los expertos en
dominio pueden ser de gran ayuda para analizar requisitos generales
y específicos.
Lluvia de ideas
Un debate informal se lleva a cabo entre varios accionistas y todos los
inputs o entradas se graban para el análisis de requisitos posterior.
Modelo de prototipos
Se basa en construir interfaces de usuario sin añadir detalles de las
funcionalidades para que el usuario interprete las características del
producto software que se quiere desarrollar. Ayuda aportando una
mejor idea de los requisitos. Si el consumidor final no tiene el software
instalado para que el desarrollador lo tome como referencia y el cliente
no sabe cuáles son sus propios requisitos, el desarrollador crea un
prototipo basado en los requisitos mencionados al inicio. El prototipo
se muestra al cliente y el feedback que se obtiene se registra. El
feedback del cliente sirve d input o entrada para la recogida de
requisitos.
Observación
El equipo de expertos visita la organización o el lugar de trabajo de
los clientes. Observan el funcionamiento de los sistemas instalados ya
existentes. También observan el flujo de trabajo y cómo se tratan los
problemas de ejecución. El equipo traza las conclusiones que ayudan
a formar los requisitos esperados para el software.
• Clara
• Correcta
• Consistente
• Coherente
• Comprensible
• Modificable
• Verificable
• Priorizada
• sin ambigüedades
• Trazable
• Origen creíble
Requisitos de Software
Debemos intentar entender qué tipo de requisitos pueden aparecer en
la fase de educción de requisitos y qué tipo de requisitos se esperan
del sistema de software.
Requisitos funcionales
Requisitos que se relacionan a aspectos funcionales del software irían
en esta categoría.
EJEMPLOS -
• Buscar una opción dada al usuario para buscar desde varias facturas.
Requisitos no funcionales
Los requisitos, los cuales no están relacionados con aspectos
funcionales del software, están en esta categoría. Son características
del software implícitas o esperadas, asumidas por los usuarios.
• Seguridad
• Acceso
• Almacenaje
• Configuración
• Actuación
• Coste
• Interoperabilidad
• Flexibilidad
• Recuperación de desastre
• Accesibilidad
• rápido en responder
• Presentación de contenido
• De fácil navegación
• Interfaces simples
• Receptivo
• Elementos consistentes de UI
• Mecanismo de retroalimentación
• Configuración Default
• Disposición significante
• Validación de requisitos
Modularización
La Modularización es una técnica para dividir sistemas de Software en
múltiples separados e independientes módulos, los cuales se espera
que sean capaces de llevar a cabo tareas(s) de forma independiente.
Estos módulos pueden funcionar como creaciones básicas para la
totalidad del software. Los diseñadores tienden a diseñar módulos que
se pueden ejecutar y/o almacenar por separado y de manera
independiente.
Concurrencia informática
Hace un tiempo, todos los softwares se hacían con la idea de que
fueran ejecutados de forma secuencial. Por secuencial se entiende que
las instrucciones codificadas serán ejecutadas una después de la otra
implicando solo una parte del programa activado en cualquier
momento. Pongamos que un software tiene múltiples módulos, en
este caso solo uno de entre todos los módulos puede estar activo en
cualquier momento de la ejecución.
Ejemplo
El corrector ortográfico del procesador de textos Word es un módulo
de software, que funciona de forma independiente al procesador de
textos mismo.
Acoplamiento y cohesión
Cuando un programa software está modularizado, sus tareas se
dividen en varios módulos en base a algunas características. Como
sabemos, los módulos son sets de instrucciones agrupados con la
finalidad de lograr ciertas tareas. Son complicados, si se consideran
como una sola entidad, pero pueden consultar al otro y trabajar de
manera conjunta. Hay formas de medir la calidad del diseño de los
módulos y de sus interacciones. Estas medidas se denominan
acoplamiento y cohesión.
Cohesión
La Cohesión es una medida que define el grado de interdependencia
entre los elementos que conforman los módulos. A mejor cohesión,
mejor diseño de programa obtenemos.
Acoplamiento
El acoplamiento es una medida que define el nivel de interdependencia
entre los módulos del programa. Nos muestra el nivel en que los
módulos interfieren e interactúan entre ellos. A menor acoplamiento,
mejor programa se obtiene.
Herramientas de Análisis y de
Diseño
El análisis y el diseño del Software incluye todas las actividades, que
ayudan a transformar los requisitos requeridos en implementación.
Los requisitos especifican la previsión operativa o no operativa del
software. La especificación de requisitos se da en documentos con un
lenguaje humano comprensible, con el que el ordenador no tiene
ninguna relación.
Tipos de DFD
Los Diagramas de flujo de datos son o físicos o lógicos
• DFD lógico - Este tipo de DFD se concentra en el proceso y en el flujo de
datos del sistema. Por ejemplo, en los sistemas de software de Banking,
se centra en cómo se mueven los datos entre distintas entidades.
Niveles de DFD
• Nivel 0 - El mayor nivel de abstracción del DFD se conoce como Nivel 0
DFD, el cual representa la totalidad de información del sistema en un
diagrama ocultando todos los detalles subyacentes. Los Niveles 0 de DFD
son también conocidos como nivel de contexto de DFD.
• Nivel 1 - El nivel 0 DFD se desglosa en un Nivel 1 DFD más específico. El
Nivel 1 DFD representa los módulos básicos del sistema así como el flujo
de información entre los distintos módulos. El Nivel 1 DFD también alude
a los procesos básicos y a las fuentes de información.
• Nivel 2 - En este nivel el DFD muestra cómo fluyen los datos en los
módulos mencionados en el Nivel 1.
Esquema gráfico
Un Esquema gráfico es un esquema derivado del Diagrama de flujo de
datos. Representa el sistema con mucho más detalle que el DFD.
Desglosa la totalidad del sistema en módulos funcionales más bajos,
describe funciones y sub-funciones de cada módulo del sistema de una
forma más exhaustiva y detallada que el DFD.
• Salto - Se trata de una flecha apuntando dentro del módulo para mostrar
que el control saltará hacia el centro del sub-módulo.
• Curva - Un flecha curvada representa que hay una curva en el módulo.
Todos los sub-módulos cubiertos por una curva repiten la ejecución del
módulo.
Diagrama HIPO
El Diagrama HIPO (Hierarchical Input Process Output) es una
combinación de dos métodos organizados para analizar el sistema y
proveer técnicas de documentación. El modelo HIPO fue desarrollado
por la empresa IBM en el año 1970.
'Structured English'
La mayor parte de los programadores no tienen un conocimiento total
en lo que se refiere al software y solo confían en las instrucciones a
seguir dictadas por sus jefes. Es responsabilidad de los altos Directivos
de Software de proveer información exhaustiva a los programadores
para poder desarrollar códigos de forma rápida y acurada.
IF-THEN-ELSE,
DO-WHILE-UNTIL
Enter Customer_Name
ELSE
ENDIF
Pseudo-Código
El Pseudo-Código se escribe de manera más cercana al lenguaje de
programación. Se puede considerar como un lenguaje de
programación popular, lleno de comentarios y de descripciones.
Ejemplo
Programa para imprimir Fibonacci a números n.
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
if a greater than b
Increase b by a;
Print b;
increase a by b;
print a;
Tablas de decisión
Una tabla de decisión representa las condiciones y las respectivas para
dirigirlas, en un formato tabular estructurado.
Ejemplo
Veamos un simple ejemplo de un problema que nos ocurre día a día
con nuestra conexión de Internet. Empezamos identificando todos los
problemas que pueden surgir mientras iniciamos Internet y sus
posibles soluciones.
Condiciones/Acciones Normas
Examina el router X X X X
• Entidad - Una entidad en modelo ER Model es un ser del mundo real, que
tiene algunas propiedades llamadas atributos. Cada atributo se define
por sus correspondientes sets de valores llamados dominio.
Por ejemplo, considere una Base de datos de una escuela. En este caso,
un estudiante sería una entidad. El estudiante tiene varios atributos como
nombre, identidad, edad, clase, etc.
Esquematizar cardinalidad:
o uno a uno
o uno a varios
o varios a uno
o varios a varios
Diccionario de datos
El Diccionario de datos es la colección central de información sobre los
datos. Almacena el significado y el origen de los datos, su relación con
otros datos, su formato de uso etc. El diccionario de datos tiene
rigurosas definiciones de todos los nombres para facilitar al Usuario y
a los diseñadores de software.
Contenidos
El diccionario de datos debe contener información sobre los siguientes
• Flujo de datos
• Almacenajes de datos
• Procesamiento de datos
= Compuesto por
{} Repetición
() Opcional
+ y
[/] O
Ejemplo
Domicilio = Número + (calle / barrio) + Ciudad + estado
• Nombre principal
Almacenamiento de datos
Almacena la información desde donde entran y salen los datos al y del
sistema. El almacenamiento de datos puede incluir -
• Archivos
o Internos al software.
• Tablas
o Propiedad de Indexación
Procesamiento de datos
Hay dos tipos de procesamiento de datos:
Diseño Estructurado
El Diseño estructurado es la conceptualización de un problema en
varios elementos organizados de solución. Está básicamente centrado
en el diseño de soluciones. El beneficio del diseño estructurado es que
da un mejor entendimiento sobre cómo se resuelve el problema. El
diseño estructurado también simplifica el proceso al diseñador, por
tanto, este último puede concentrarse en el problema de forma más
acurada.
Proceso de diseño
Bottom-up Design
El modelo de Diseño 'bottom up' (de abajo a arriba) empieza con
componentes más básicos y específicos. Continúa formando un mayor
nivel de componentes usando un nivel básico o bajo de componentes.
Sigue creando componentes de alto nivel hasta el punto en el que el
sistema deseado no ha evolucionado en un solo componente. Como
mayor sea el nivel más incrementará la abstracción.
Software - Diseño de UI
La interfaz de usuario es la parte visible de la aplicación front-end
(traducible al español como interfaz) con la que el usuario interacciona
a fin de usar el software. El usuario puede manipular y controlar el
software, así como el hardware por medio de las interfaces de usuario.
Hoy en día, la interfaz de usuario se encuentra casi en todos los
lugares donde existe tecnología digital, desde ordenadores, móviles,
coches, reproductores de música, aviones, barcos, etc.
• Atractiva
• Fácil de usar
• De respuesta rápida
• Clara de comprender
Una CLI en forma de texto puede tener los elementos que se exponen
a continuación:
Elementos de la GUI
La GUI ofrece un conjunto de componentes para interactuar con el
software o con el hardware.
• Sliders
Herramientas de implementación de la
GUI
Hay muchas herramientas disponibles con las que los diseñadores
pueden crear la totalidad de las GUI. Algunas herramientas se pueden
incorporar en entorno software(IDE).
Ejemplo
GUI para móvil, para ordenador, para pantalla táctil, etc. Aquí se
enumeran algunas herramientas útiles para la construcción de una
GUI:
• FLUID
• AppInventor (Android)
• LucidChart
• Wavemaker
• Visual Studio
Parámetro Significado
n Vocabulario n1 + n2
N medida N1 + N2
Dibuje un arco
Dibuje un arco.
V(G) = e – n + 2
Where
e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2 = 4
Entrada externa
Cada entrada del sistema, desde fuera, se considera entrada externa.
La singularidad de la entrada se mide, ya que dos entradas no deben
tener el mismo formato. Estas entradas pueden ser o datos o
parámetros de control.
Salida externa
Todos los tipos de salida que da el sistema forman parte de esta
categoría. La salida se considera única si su formato de salida y/o su
procesamiento son únicos.
Consulta externa
Una consulta es la combinación de una entrada y una salida, cuando
el usuario envía algún dato para consultar como entrada y el sistema
responde al usuario con una salida de consulta procesada. La
complejidad de la consulta es más alta que la entrada externa y la
salida externa. La consulta es única si sus entradas y salidas son
también únicas en lo que se refiere al formato y a los datos.
Entradas 3 4 6
Salidas 4 5 7
Consulta 3 4 6
Archivos 7 10 15
Interfaces 5 7 10
• Comunicación de datos
• Computación distribuida
• Objetivos de actuación
• Tasa de la transacción
• Actualización online
• Reutilización
• Facilidad de Instalación
• Facilidad operativa
• Webs Múltiples
• Sin influencia
• Adicional
• Moderado
• Medio
• Significante
• Esencial
Luego,
Coste = $ / FP
Calidad = Errores / FP
Productividad = FP / persona-mes
Software - Implementación
En este capítulo, estudiaremos métodos de programación,
documentación y retos en la implementación de Software.
Programación estructurada
En el proceso de codificación, las líneas del código se multiplican
continuamente, por consiguiente, el tamaño del software se
incrementa. Se vuelve casi imposible recordar el flujo del programa
gradualmente. Si nos olvidamos cómo se construyen el software y sus
subyacentes programas, los archivos... resulta muy difícil compartir,
modificar y eliminar los fallos del programa. La solución yace en la
programación estructurada. Motiva al desarrollador a usar subrutinas
y estructuras de control (loops) en vez de usar simples saltos en el
código, de este modo haciendo el código más claro y mejorando su
eficiencia, la programación estructurada también ayuda al
programador a reducir el tiempo de codificación y a organizar el
lenguaje de programación correctamente.
Programación funcional
La programación funcional es un estilo de lenguaje de programación,
que usa conceptos de funciones matemáticas. En matemáticas una
función siempre debe producir el mismo resultado si recibe el mismo
argumento. En un lenguaje procedimental, el flujo del programa
funciona a través de procedimientos, esto es, el control del programa
se transfiere al procedimiento mencionado. Mientras el flujo de control
se transfiere de un procedimiento a otro, el programa cambia su
estado.
Estilo de programación
El estilo de programación se configura con reglas de codificación
seguidas por todos los programadores para escribir el código. Cuando
más de un programador trabaja en el mismo proyecto de software,
necesitan frecuentemente trabajar con el código del programa que ha
escrito otro desarrollador. Esto se vuelve tedioso o a veces imposible,
si todos los desarrolladores no siguen un estilo de programación
estándar para codificar el programa.
Directrices de codificación
Las distintas prácticas de estilo de codificación varían en cada
organización, sistema operativo, y en el mismo lenguaje de
codificación.
Documentación de Software
La documentación de Software es una parte importante del proceso
de software. Un documento bien escrito es una gran herramienta y es
un medio repositorio de información necesario para conocer el proceso
de software. La documentación de Software también aporta
información sobre cómo se debe usar el producto.
Retos de la implementación de
Software
Hay algunos retos que el equipo de desarrollo debe afrontar mientras
se implementa el software. Algunos de ellos se explicitan a
continuación:
Verificación Software
La verificación es el proceso de confirmación del cumplimiento de los
requisitos empresariales por parte del software, y se desarrolla
ciñéndose a especificaciones y metodologías adecuadas.
El Target de la prueba es -
• Pruebas funcionales
• Pruebas de implementación
Los tests exhaustivos son los métodos más deseados para una
evaluación perfecta. Cada valor posible en el rango de valor de
entrada y salida es evaluado. No es posible evaluar cada valor del
mundo real si el rango d valores es grande.
• Evaluación del flujo de datos - Esta técnica enfatiza en cubrir todas las
variables de datos incluidas en el programa. Evalúa dónde se declaran,
definen, se usan o cambian las variables.
Niveles de evaluación
La evaluación por sí misma se puede definir en varios niveles de SDLC.
El proceso evaluador se lleva a cabo en paralelo al desarrollo del
software. Antes de lanzarnos a la siguiente etapa, la etapa se evalúa,
valida y verifica.
Evaluar de forma separada se hace para asegurar que no hay defectos
escondidos o asuntos que se han dejado de lado en el software. El
Software se evalúa en varios niveles -
Evaluación unitaria
Mientras se codifica, el programador hace algunos tests en esa unidad
de programa para saber si está libre de errores. La evaluación se lleva
a cabo con técnicas de caja blanca. La evaluación unitaria ayuda a los
desarrolladores a decidir que las unidades del programa funcionan
según los requisitos y están libres de errores.
Pruebas de integración
Aunque las unidades del software funcionen bien de forma individual,
se necesita encontrar si las unidades que están integradas y juntas
también funcionan sin errores. Por ejemplo, actualización de datos,
etc.
Tests de aceptación
Cuando el software está listo para ser entregado al cliente tiene que
pasar por la última fase de evaluación donde se comprobará su
interacción con el usuario y su capacidad de respuesta. Esto es
importante porque, aunque el software cumpla todos los requisitos del
consumidor, si al usuario no le gusta su apariencia o su forma de
funcionar, puede ser que acabe por ser rechazado.
• Pruebas Alpha - El equipo de desarrolladores hacen la evaluación 'Alpha'
usando el sistema como si ya se estuviera en un entorno de trabajo.
Intentan así averiguar cómo reaccionaría el usuario a alguna acción del
software, y cómo el sistema debe responder a entradas o inputs distintos.
Pruebas de regresión
Cuando un producto software se actualiza con un nuevo código o con
nuevas características o funcionalidades, se evalúa para detectar si
hay algún impacto negativo con lo que se ha añadido. Este proceso se
conoce como prueba de regresión.
Documentación evaluativa
Los tests se preparan en diferentes etapas -
Antes de evaluar
Las pruebas empiezan con la generación de tests demo. Para ello se
necesitan los siguientes documentos de referencia –
Software - Mantenimiento
El mantenimiento del Software es hoy en día aceptado comparte del
SDLC. Se refiere a todas las modificaciones y actualizaciones que se
llevan a cabo después de la entrega del producto software. Hay
muchas razones por las que las modificaciones son necesarias,
algunas de ellas se mencionan de manera breve a continuación:
Coste de Mantenimiento
Los informes insinúan que el coste de mantenimiento es alto. Un
estudio realizado para estimar el mantenimiento de software concluyó
que el coste de mantenimiento representa un 67% del coste total en
el ciclo del proceso de software.
El promedio del coste del mantenimiento de software constituye más
del 50% en todas las fases del SDLC. Hay varios factores, que inducen
el aumento del coste de mantenimiento, como es el caso de:
• Lenguaje de programación
Actividades de mantenimiento
El IEEE proporciona un borrador para las actividades del proceso
secuencial de mantenimiento. Se puede usar de forma reiterativa y
puede extenderse para que los artículos personalizados puedan
incluirse.
Estas actividades van cogidas de la mano con cada una de las
siguientes fases:
Refactorización de Software
Cuando necesitamos actualizar el software para mantenerlo en el
mercado actual, sin afectar a su funcionalidad, estamos ante un caso
de refactorización de software. Es un proceso en el que el diseño del
software se cambia y los programas se escriben de nuevo.
Proceso de refactorización
• Decidir Lo que va a ser refactorizado, si va a ser una parte del software
o su totalidad.
• Desarrollar La ingeniería inversa, con tal de obtener especificaciones de
software ya existentes.
Ingeniería inversa
Es un proceso para lograr especificaciones del sistema a través del
análisis y el entendimiento del sistema existente. Este proceso puede
verse como un modelo inverso de SDLC, esto es, intentamos lograr
mayor nivel de abstracción analizando niveles de abstracción más
bajos.
Reestructurar el Programa
Es un proceso de reestructuración y construcción de software ya
existente. Se vuelve a organizar el código de origen, en el mismo
lenguaje de programación o con otro distinto. La reestructuración
puede tener su origen en la reestructuración del código, de los datos
o de ambos.
Ingeniería directa
La ingeniería directa es un proceso para obtener el software deseado
a partir de los requisitos que se han obtenido mediante la ingeniería
invertida. Asume que había alguna ingeniería de software ya hecha en
el pasado.
Reutilización de componentes
Un componente es parte del código del programa software, el cual
ejecuta tareas independientes en el sistema. Puede ser un módulo
pequeño o un subsistema en sí mismo.
Ejemplo
Los procedimientos de acceso que se usan en las webs se pueden
considerar como componentes, el sistema de impresión en software
se puede considerar como componente del software.
Proceso de reutilización
Se pueden adoptar dos tipos de método: o manteniendo los requisitos
de la misma manera y ajustando los componentes, o manteniendo los
componentes igual, pero modificando los requisitos.
• Requisitos del sistema - Los requisitos funcionales y no funcionales del
producto software se especifican, y este debe cumplirlos, con la ayuda
del sistema existente, una entrada (input) de un usuario, o con ambos.
Herramienta CASE
Las herramientas CASE son un conjunto de aplicaciones informáticas,
usadas para automatizar actividades del ciclo de vida de desarrollo de
sistemas (SDLC). Las herramientas CASE son usadas por los
Directores de proyectos de software, analistas e Ingenieros para
desarrollar sistemas de software.
Herramientas de documentación
La documentación de un proyecto de software empieza antes que el
proceso de software, pasa por todas las fases del SDLC y se concluye
con la terminación del proyecto.
Herramientas de análisis
Estas herramientas ayudan a cumplir con los requisitos, de manera
automática examinan si hay alguna inconsistencia, o informaciones no
acuradas en los diagramas, buscan posibles redundancias u omisiones
erróneas. Ejemplos de este tipo de herramienta son Accept 360,
Accompa, CaseComplete para análisis de requisitos, y Visible Analysts
para análisis total.
Herramientas de diseño
Estas herramientas ayudan a los diseñadores de software a crear la
estructura de los programas, la cual se puede más adelante desglosar
en pequeños módulos usando técnicas de perfeccionamiento. Estas
herramientas aportan los detalles de cada módulo y la interconexión
presente entre estos. Un ejemplo de herramienta puede ser el diseño
animado de software
• Control de versiones
• Línea base
• Gestión del control de cambios
Programming Tools
These tools consist of programming environments like IDE (Integrated
Development Environment), in-built modules library and simulation
tools. These tools provide comprehensive aid in building software
product and include features for simulation and testing. For example,
Cscope to search code in C, Eclipse.
Herramientas de mantenimiento
El mantenimiento del Software incluye modificaciones en el producto
software después de ser distribuido. Algunas de las herramientas
CASE que ayudan en la organización y la fase de mantenimiento del
software del SDLC son las técnicas de inicio automático y de reporte
de error, producción automática de etiqueta de error y de Análisis de
Causa Raíz (ACR o RCA en sus siglas en inglés). Por ejemplo, Bugzilla
para seguimiento de defectos, HP Quality Center.
Q. ¿Qué es SRS?
Q. ¿Qué es modularización?
Ejemplo
Mientras usted inicia el comando de impresión y comienza a imprimir,
puede abrir una nueva aplicación.
Q. ¿Qué es acoplamiento?
• correctivo
• Adaptado
• Mantenimiento perfectivo
• El mantenimiento preventivo
Tomar las medidas apropiadas para evitar problemas en el futuro
¿Cuál es siguiente?.
Además, usted puede ir a través de sus asignaciones anteriores que
has hecho con el tema y asegurarse de que son capaces de hablar con
confianza en ellos. Si usted es más fresco luego entrevistador no
espera que usted contestará preguntas muy complejas, y no tienes
que hacer que sus conceptos básicos muy fuerte.