Línea de Código (LOC)

Línea de Código(LOC)Una de las métricas más usadas es la del número de líneas de código (LOC), que aunque parece sencilla no lo es tanto, ya que existen diferentes alternativas: contar sólo las líneas de código ejecutable, añadirle las declaraciones de datos, también podemos contas las líneas de comentarios, añadir las sentencias de control, etc. etc. De hecho suele ser frecuente, que al usar diferentes programas de métricas, estas generen diferentes valores de LOCs para un mismo fichero. El uso principal que tiene contar líneas de código, es poder determinar proporciones entre líneas de código y fallos, es decir, generar medidas (y heurísticas) sobre el número de líneas de código y el número de fallos de una aplicación (‘número de defectos por KLOC (1000 LOC)’).

Una alternativa a las líneas de código son los puntos de función, que también intentan medir el tamaño del software. Este es bastante independiente del lenguaje de programación utilizado. Sacado de la Wikipedia: la técnica de medición del tamaño en punto-función consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Como podemos ver, bastante compleja de calcular.2.2.- Complejidad ciclomática.

La métrica de la complejidad ciclomática fue diseñada por McCabe (1976) para indicar la facilidad para testear y entender el código. Esta medida está secada de la teoría de grafos, e indica el número de regiones en un grafo.
Aplicada al software, es el número de caminos linealmente independientes que contiene un programa. Como tal, puede ser usado para indicar el esfuerzo necesario para testear un programa.
Tomado de la Wikipedia: La complejidad ciclomática de un bloque de código fuente es el número de caminos ejecutables en el código fuente. Por ejemplo si el código fuente no contiene puntos de decisión (es decir no contiene instrucciones IF, ni For, etc) la complejidad ciclomática sería igual a 1, ya que sólo existe un camino de ejecución para ese código. Si el código contuviera un IF entonces existirían dos, uno si la expresión condicional del IF resulta cierta, y otro para cuando es falsa.

Existen numerosos estudios empíricos que han demostrado una alta correlación entre código con fallos y código con alta complejidad ciclomática.

3.- Descripción de la LOCE (Lines Of Code Equivalence, Equivalencia en número de líneas de código).

LOCE viene de “Lines Of Code Equivalence”, es decir, “Equivalencia en Número de Líneas de Código”, y como ya hemos dicho es una métrica que intenta mejorar las métricas de conteo de número de líneas y de complejidad ciclomática, ya que ¿acaso es igual de complejo un método con 3 IF separados que con 3 bucles FOR anidades? No lo creemos.

ToroMetrics hace una suposición muy sencilla y es que cuanto más anidada está una línea de código más difícil es de entender, o lo que es lo mismo, más complejo es el código y más probabilidades tiene de contener un error, ya que una línea de código dentro de un IF o un FOR podrá o no ejecutarse, o incluso ejecutarse numerosas veces, por lo general tendrá una semántica adicional y tendrá una relación más estrecha con el resto de líneas de código de su bloque.

La medición de la LOCE de una sentencia será sencilla, si la línea está directamente dentro del método diremos que está a nivel de profundidad igual a 0, si está anidada dentro de sentencias IF, FOR, WHILE, y DO tendrá un nivel de produndidad igual a la suma de estas sentencias que la engloben. La LOCE de una línea será por tanto:
 Para niveles igual a cero, su LOCE será uno.
 Para niveles mayores que cero, su LOCE será 2 * Nivel.

La LOCE del método (el peso del método) sería igual al sumatorio del peso de cada una de sus líneas.

El número 2 representaría el incremento de complejidad por estar dentro de una rama de la ejecución (un IF, FOR, WHILE, etc).

Veamos un pequeño ejemplo con la clase Dummy para ver cómo funciona esta aplicación:

package org.opentoro.utils.metrics;

public class Dummy {
public Dummy() {
}
public void doit(){
for (int i = 0; i < 10; i++){
for(int j = 0; j < i; j++){
System.out.println("i = " + i);
System.out.println("j = " + j);
}//End For j
}//End For i
}
}
[Referencia1]: www.freetutes.com/systemanalysis/sa3-lines-of-code.html

La Norma ISO 9001.

La Norma ISO 9001 ha sido elaborada por el Comité Técnico ISO/TC176 de ISO Organización Internacional para la Estandarizaciòn y especifica los requisitos para un buen sistema de gestión de la calidad que pueden utilizarse para su aplicación interna por las organizaciones, para certificación o con fines contractuales.
La norma ISO 9001 tiene origen en la norma BS 5750, publicada en 1979 por la entidad de normalización británica, la [British Standards Instituti] (BSI).
La versión actual de ISO 9001 (la cuarta) data de noviembre de 2008, y por ello se expresa como ISO 9001:2008. Versiones ISO 9001 hasta la fecha:
• Cuarta versión: la actual ISO 9001:2008 (15/11/2008)
• Tercera versión: ISO 9001:2000 (15/12/2000)
• Segunda versión: ISO 9001:94 - ISO 9002:94 - ISO 9003:94 (01/07/1994)
• Primera versión: ISO 9001:87 - ISO 9002:87 - ISO 9003:87 (15/03/1987).
• En la primera y segunda versión de ISO 9001, la Norma se descomponía en 3 normas: ISO 9001, ISO 9002, e ISO 9003.
• ISO 9001 --> organizaciones con diseño de producto
• ISO 9002 --> organizaciones sin diseño de producto pero con producción/fabricación.
• ISO 9003 --> organizaciones sin diseño de producto ni producción/fabricación (comerciales).
El contenido de las 3 normas era el mismo, con la excepción de que en cada caso se excluían los requisitos de aquello que no aplicaba. Esta mecánica se modificó en la tercera versión, unificando los 3 documentos en un único estándar, sobre el cual se realizan posteriormente las exclusiones.
La cuarta versión de la norma presenta más de 60 modificaciones que se reparten de la siguiente forma.[Referencia1]: http://es.wikipedia.org/wiki/ISO_9001.

Six Sigma (Seis Sigma).

Seis Sigma es una metodología de mejora de procesos, centrada en la reducción de la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos o fallas en la entrega de un producto o servicio al cliente. La meta de 6 Sigma es llegar a un máximo de 3,4 defectos por millón de eventos u oportunidades (DPMO), entendiéndose como defecto cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente.
Seis sigma utiliza herramientas estadísticas para la caracterización y el estudio de los procesos, de ahí el nombre de la herramienta, ya que sigma representa tradicionalmente la variabilidad en un proceso y el objetivo de la metodología seis sigma es reducir ésta de modo que mi proceso se encuentre siempre dentro de los límites establecidos por los requisitos del cliente.[Referencia1]: http://es.wikipedia.org/wiki/Six_Sigma.

RUP.

El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.[Refercia1]: http://es.wikipedia.org/wiki/RUP

PMBOK .

El cuerpo de conocimiento de proyectos (PMBOK) es un término inclusivo que describe la suma de los conocimientos dentro de la profesión de administración de proyectos. Como en otras profesiones tales como: medicina, abogacía, contaduría, el cuerpo del conocimiento recae sobre profesionales y académicos que aplican ese conocimiento y lo avanzan. El PMBOK entero incluye conocimiento probado y prácticas tradicionales que se aplican ampliamente, además del conocimiento e innovaciones de prácticas avanzadas que han visto un uso más limitado. Este capítulo define y explica varios términos claves y provee una vista general del resto del documento. Además incluye las

Siguientes secciones principales:

· Propósito de este documento

· Qué es un proyecto?

· Qué es la administración de proyectos?

· Relación con otras disciplinas de administración

· Tareas relacionadas

El propósito primario de este documento es identificar y describir ese subjuego del PMBOK que es generalmente aceptado. Generalmente aceptado quiere decir que el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos la mayoría de las veces, y que hay un consenso amplio sobre su valor y utilidad. Generalmente aceptado no quiere decir que las prácticas y el conocimiento son o deben ser aplicadas uniformemente a todos los proyectos; el equipo de administración de proyectos siempre será responsable de determinar que es apropiado para cualquier proyecto dado. Referencia1: http://www.scribd.com/doc/7107146/PM-Administracion-de-Proyectos-PMI-PMBOK

La Guía del PMBOK® es un estándar en la gestión de proyectos desarrollado por el Project Management Institute (PMI). La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto. En 1987, el PMI publicó la primera edición del PMBOK® en un intento por documentar y estandarizar información y prácticas generalmente aceptadas en la gestión de proyectos. La edición actual, la cuarta, provee de referencias básicas a cualquiera que esté interesado en la gestión de proyectos. Posee un léxico común y una estructura consistente para el campo de la gestión de proyectos. [Referecia 2]: http://es.wikipedia.org/wiki/Project_Management_Body_of_Knowledge

El PMBOK es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.

El 'PMBOK' reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos.

Los procesos se traslapan e interactúan a través de un proyecto o fase. Los procesos son descritos en términos de: Entradas (documentos, planes, diseños, etc.), Herramientas y Técnicas (mecanismos aplicados a las entradas) y Salidas (documentos, productos, etc.). Las diez áreas del conocimiento mencionadas en el PMBOK son:

Gestión de la Integración
Gestión del Alcance
Gestión del Tiempo
Gestión de la Calidad
Gestión de Costos
Gestión del Riesgo
Gestión de Recursos Humanos
Gestión de la Comunicación
Gestión de las Compras y Adquisicione.[Referecia 3]: http://www.12manage.com/methods_pmi_pmbok_es.html.

Bienvenida

he creado este blogs para la trasnferencia de tareas, investigaciones y toda clase de archivo que utilizaremos en Gerencia de Proyecto Informaticos, mi nombre es Nehemias C. Carrera estudiante de ing. de sistemas de informacion en la Universidad Tecnologica de Panamà. En esta materia deseo adquirir los conocimientos necesario para la creacion de proyectos informaticos utilizados en el campo laboral de los sistemas de informacion y asi mismo desarrollar un buen proyecto que sera de gran ayuda en mi profesion.