Unidad III

El software, como bien de capital


Los bienes de capital son conocimiento empaquetado acerca de cómo realizar algún tipo de producción El conocimiento que hay que empaquetar es disperso, incompleto, cambiante, en gran parte tácito y crecientemente complejo.

Desde un punto de vista económico, el software es un medio de producción englobado dentro del capital intelectual de la empresa. Como cualquier otro medio de producción, en su fase de uso puede verse como conocimiento empaquetado.

Su fase de desarrollo, consistente en reunir y empaquetar en la forma adecuada los conocimientos necesarios para realizar algún tipo de producción, se ha transformado, debido a las características específicas del software, a la complejidad creciente de los objetivos de producción y a la naturaleza muy evolutiva de los conocimientos necesarios, en un sofisticado proceso de aprendizaje social, sometido por ende a las reglas de productividad y competencia económicas. De forma general, la producción y el uso (precedido de la contratación) de software forman parte del amplio campo de lo que ahora se llama “gestión del conocimiento”.

para mayor informacion ingresa en:

http://www.gsi.dit.upm.es/~fsaez/intl/ingenieria_del_software_factores_economicos_y_humanos.pdf

PeopleWare

Como no podemos modificar la naturaleza humana, los miedos, las confusiones y los traumas de las situaciones de cambio resultantes de nuevos procesos, nuevos sistemas, nuevas políticas, etc.; necesitamos gerenciar las modificaciones. También en el Gerenciamiento de Cambios, buscamos trabajar de forma simple y respetando la cultura y la realidad de cada cliente. Aquí, el Factor Humano, o "PeopleWare" es lo esencial.

Cuando reducimos los miedos, las agendas ocultas, las ansiedades de las situaciones de cambio y aumentamos la integración y la receptividad de las personas involucradas, reducimos muchísimo la "pérdida de carga", la pérdida de tiempo y energía y mejoramos nuestra propia calidad de soluciones, con costos menores y menor riesgo. La mayor parte de los problemas en nuevos procesos, nuevos sistemas y nuevas políticas son causados por Factores Humanos..

La dimensión humana es un factor crítico en toda organización, especialmente en aquellas donde el proceso de producción es básicamente un proceso intelectual, tal como sucede en el proceso de construcción de software. Uno de los aspectos más importantes referidos a los recursos humanos involucrados en el desarrollo de software es la determinación de las necesidades de competencias para el desempeño adecuado de los distintos roles.


Para saber mas del tema se recomienda entrar al siguiente link.

http://caribdis.unab.edu.co/pls/portal/docs/PAGE/REVISTACOLOMBIANACOMPUTO/RCC_ESPANOL/NUMEROSANTERIORES/DICIEMBRE2006/R72_ART3_C.PDF

Unidad II

Gestión de Proyectos de software

El paradigma orientado a objetos:

La programación orientada a objeto surge de la necesidad de simplificar la estructura de los programas para animar al desarrollador a concentrarse en en sus objetivos.

Enlace para ampliar la información del tema:

http://www.pol.una.py/archivos/asi/paradigmas/programacion_orientada_objetos.pdf

Ejemplo de POO en C Sharp
En el siguiente ejemplo tomado del libro Cómo programar en C Sharp de Deitel, se utiliza una clase llamada tiempo. Dicha clase posee tres atributos (hora, minuto, segundo; todos variables enteras), y tres métodos. Vamos con el código, y para una explicación visitar: http://casidiablo.net/poo-c-sharp/#more-2268

using System;
public class Tiempo
{
private int hora; // 0 -23
private int minuto; // 0-59
private int segundo; // 0-59
// Constructor de la clase Tiempo que inicialize
//las variables a cero para poner la hora en media noche
public Tiempo()
{
cambiarHora( 0, 0, 0 );
}
// este metodo asigna una nueva hora en formato 24-horas.
public void cambiarHora(
int valorHora, int valorMinuto, int valorSegundo )
{
hora = ( valorHora >= 0 && valorHora < 24 ) ?
valorHora : 0;
minuto = ( valorMinuto >= 0 && valorMinuto < 60 ) ?
valorMinuto : 0;
segundo = ( valorSegundo >= 0 && valorSegundo < 60 ) ?
valorSegundo : 0;
}
// convertir a hora universal con el metodo format
public string horaUniversal()
{
return String.Format(
"{0:D2}:{1:D2}:{2:D2}", hora, minuto, segundo );
}
// convertir a tiempo estandar (12 horas) usando el metodo format
public string horaEstandar()
{
return String.Format( "{0}:{1:D2}:{2:D2} {3}",
( ( hora == 12 hora == 0 ) ? 12 : hora % 12 ),
minuto, segundo, ( hora < 12 ? "AM" : "PM" ) );
}
} using System;
public class Tiempo
{
private int hora; // 0 -23
private int minuto; // 0-59
private int segundo; // 0-59
// Constructor de la clase Tiempo que inicialize
//las variables a cero para poner la hora en media noche
public Tiempo()
{
cambiarHora( 0, 0, 0 );
}
// este metodo asigna una nueva hora en formato 24-horas.
public void cambiarHora(
int valorHora, int valorMinuto, int valorSegundo )
{
hora = ( valorHora >= 0 && valorHora < 24 ) ?
valorHora : 0;
minuto = ( valorMinuto >= 0 && valorMinuto < 60 ) ?
valorMinuto : 0;
segundo = ( valorSegundo >= 0 && valorSegundo < 60 ) ?
valorSegundo : 0;
}
// convertir a hora universal con el metodo format
public string horaUniversal()
{
return String.Format(
"{0:D2}:{1:D2}:{2:D2}", hora, minuto, segundo );
}
// convertir a tiempo estandar (12 horas) usando el metodo format
public string horaEstandar()
{
return String.Format( "{0}:{1:D2}:{2:D2} {3}",
( ( hora == 12 hora == 0 ) ? 12 : hora % 12 ),
minuto, segundo, ( hora < 12 ? "AM" : "PM" ) );
}
}

Con el siguiente código, utilizamos la clase Tiempo:

using System;
class PruebaTiempo {
static void Main( string[] args ) {
Tiempo tiempo = new Tiempo(); // llamada al constructor de Tiempo
string salida;
// mostrar datos iniciales
salida = "Hora universal inicial es: " +
tiempo.horaUniversal() +
"\nHora estandar inicial es: " +
tiempo.horaEstandar();
// cambiar hora (valida)
tiempo.cambiarHora( 13, 27, 6 );
// aniadir nueva hora a la salida
salida += "\n\nHora universal despues de cambiada: " +
tiempo.horaUniversal() +
"\nHora estandar despues de cambiada: " +
tiempo.horaEstandar();
// cambiar hora (invalida)
tiempo.cambiarHora( 99, 99, 99 );
salida += "\n\nDespues de poner valores invalidos: " +
"\nHora universal: " + tiempo.horaUniversal() +
"\nHora estandar: " + tiempo.horaEstandar();
Console.WriteLine( salida );
}
}

El resultado del programa es el siguiente:
Hora universal inicial es: 00:00:00

Hora estandar inicial es: 12:00:00 AM

Hora universal despues de cambiada: 13:27:06

Hora estandar despues de cambiada: 1:27:06 PM

Despues de poner valores invalidos:

Hora universal: 00:00:00

Hora estandar: 12:00:00 AM

Gestión de proyectos de software orientados a objetos:

Material sobre Desarrollo de Proyectos de Software Orientado a Objetos: http://74.125.47.132/search?q=cache:UzaQedeocKoJ:https://www.u-cursos.cl/ingenieria/2005/2/IN77J/1/material_docente/objeto/72949+gestion+de+proyectos+de+software+orientados+a+objetos&cd=3&hl=es&ct=clnk&gl=ve

Mapa mental de Ing. de Requisitos

La Ingenieria de requisitos en la mejora del proceso de software

El CMM contiene cinco etapas para evaluar que tan sofisticada es una organización en el establecimiento y apego a procesos estándares.

Modelo SPICE

Es el modelo de evaluación y mejora de procesos software de ISO 12207

Consideraciones

Ciclo de vida para la especificacion de requisitos de software

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo.

No existe un proceso "industrial" estándar de fabricación de software. Cada caso es un mundo y puede resolverse de mil maneras, pero sin embargo, sí hay unas pautas generales para organizar el proceso, unas actividades que se repiten una y otra vez en la construcción de cualquier software. Esas actividades necesitan de una cierta organización en su realización.

Actividades del ciclo de vida del software.

• Identificación del sistema. Puede parecer una tontería, pero es más importante de lo que parece. Hay que saber qué es lo que se quiere hacer y qué es lo que no se quiere hacer. A la hora de desarrollar un producto de software siempre hay algo más que se puede hacer. En la realidad unas cosas están enlazadas con otras, y si se quiere contemplar todo en el software se puede convertir en una bestia difícil de manejar e inútil. Es necesario establecer LÍMITES. Fijar lo que debe hacer el sofware y lo que no. Qué datos debe manejar y cuáles no. Con quién o qué se debe comunicar y con quién o qué no. Esta es una tarea de análisis.

• Toma de requisitos. Tradicionalmente se ha llamado así a la actividad de plasmar por escrito o gráficamente, pero de manera lo más formal posible todas aquellas cosas que el software debe poder hacer. Entendemos por "formal" una forma de expresarse lo más completa posible y sin ambigüedades, es decir, con poco o ningún margen a la interpretación. Esta también es una tarea de análisis, que suele dar como resultado uno o más documentos conocidos como Especificación de Requisitos del Software (SRS). Existe un intento de estandarización del SRS por parte del IEEE, el conocido como IEEE-STD-830-1998, aunque sus recomendaciones son útiles como punto de partida, su aplicacion total es bastante discutible.

• Estudio de procesos. Todas las organizaciones basan su trabajo en procesos. Digamos que son rutinas más o menos establecidas para tratar un determinado asunto. El estudio de procesos se basa en identificar cuáles son esos procesos, para qué sirven, quién los realiza. Es una actividad de análisis. Suelen utilizarse diagramas gráficos para esta labor, como por ejemplo, los antiguos DFD, o los actuales diagramas de UML.

• Reingeniería de procesos. La gran olvidada en la producción del sofware. A menudo, los procesos empresariales están viciados por la tradición, la costumbre y la burocracia. Es bueno pararse a pensar si un proceso puede reorganizarse e incluso obtener otro equivalente de tal manera que el resultado siga siendo el mismo pero de manera más eficiente e incluso más eficaz. En muchos casos puede hacerse. Eso es la reingeniería. Si un proceso es ineficiente o ineficaz y se automatiza directamente, lo único que conseguiremos es que se muestre más rápidamente su ineficiencia o ineficacia.

• Diseño: Las actividades de diseño cubren todo tipo de decisiones, pero especialmente las relacionadas con "cómo va a ser el software"... de qué grandes partes constará, qué tecnología utilizará, cómo se interrelacionan los datos que va a utilizar. Por hacer un simil con la arquitectura, el diseño es al proyecto de sofware como los planos son a un edificio. También forma parte del diseño el decidir qué pequeñas piezas forman el todo: cuál es la función de cada una de ellas y cómo se comunica con las demás. El punto de partida para el diseño es la especificación de requisitos (SRS).

• Planificacion: Cuando se conoce el diseño, es necesario decidir cómo se organizará el trabajo hasta la conclusión del proyecto, desde el punto de vista de la administración de recursos, tanto humanos como materiales, y del tiempo, el espacio y el dinero. Es una tarea de diseño.

• Codificación/Implementación/Programación. Tres nombres para la misma cosa. Nos referimos a la programación propiamente dicha de cada uno de los pequeños componentes que formarán el software, siguiendo el diseño. Cada componente debe realizar la función que se le exige, y debe comunicarse con otros componentes de la manera que haya sido fijada en el diseño. Es una tarea de producción.

• Integración. Integrar es unir dos o más componentes del proyecto de sofware y verificar que todo funciona según lo diseñado, prestando especial atención al funcionamiento conjunto de los componentes. Integrando, integrando... se obtiene el proyecto entero. Es una tarea de producción.

• Pruebas: Las pruebas son muy importantes en el desarrollo del sofware. Consisten en verificar que lo que se está haciendo va bien.

• Implantación. Implantar un software es ponerlo en marcha en su ubicación definitiva. Es una tarea de producción.

• Explotación. No es una actividad o tarea en sí. Se denomina así al hecho de utilizar el sistema y sacarle partido.

• Mejora. Cuando el sistema está en explotación, es decir, en marcha, a veces es necesario introducir mejoras. Es una tarea de mantenimiento.

• Ampliación. Al igual que con las mejoras, a veces es necesario introducir nuevas funcionalidades (requisitos) en el producto de software cuando ya está en marcha. Es una tarea de mantenimiento.

• Corrección de errores. Los errores suelen aparecer con frecuencia en el software cuando está ya en marcha, aun cuando se dedique gran cantidad de esfuerzo a las pruebas.

Estas y algunas otras son las que mencionan con caracter general los libros de ingeniería del software.

Ingenieria de Requisitos

Algunos conceptos para entender que es la Ingenieria de Requisitos

• Constituyen el enlace entre las necesidades reales de los clientes, usuarios y otros participantes vinculados al sistema. La ingeniería de requisitos consiste en un conjunto de actividades y transformaciones que pretenden comprender las necesidades de un sistema software y convertir la declaración de estas necesidades en una descripción completa, precisa y documentada de los requerimientos del sistema siguiendo un determinado estándar.

• Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Una representación documentada de una condición o capacidad de un sistema.

http://danielvn7.wordpress.com/2008/03/27/%C2%BFque-es-ingenieria-de-requisitos-ir/

Resumiendo los conceptos podemos decir que la Ingenieria de Requisitos:

Es el conjunto de procesos, técnicas y herramientas que rige toda petición de las unidades de negocio para conseguir:

• Una comprensión de la necesidad o problemática completa.
• Conocer la complejidad e impacto en el negocio.
• Realizar el primer acercamiento al lenguaje utilizado en Sistemas de Información.

Documento de especificacion de requisitos de software

Como se menciona en [Pressman, 1998], la especificación de los requisitos del software implica la culminación de la tarea del análisis de sistemas. Dicha especificación se logra estableciendo una completa descripción de las clases que colaboran, su función y el comportamiento del sistema. Este documento y el modelado que contiene deben lograr tres
objetivos en mente:

• Describir lo que requiere el usuario.
• Establecer una base para la creación de un diseño de software.
• Definir un conjunto de requisitos que se puedan validar una vez que se ha construido
  el software.

lo que debe contener un documentos de especificacion de requisitos de software

Para estudiar mejor este tema veamos una metodologia que aplica algunos conceptos de la unidad IV

Microsoft Solution Framework (MSF). http://www.gpicr.com/msf.aspx

Todo proyecto es separado en cinco principales fases:

• Visión y Alcances.
• Planificación.
• Desarrollo.
• Estabilización.
• Implantación.

De las cuales solo tomaremos en cuenta las primeras dos.

Visión y Alcances:

La fase de visión y alcances trata uno de los requisitos más fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común. El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente.

Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.

Planificación:

Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.

De esta manera, se logran establecer la bases para un buen diseño de sistemas, documentando una descripción del problema.