Sebastian Durandeu Blog

  • Visitantes

The Business of Software de Michael Cusumano

Posted by sebastiandurandeu on June 10, 2010

Para la materia Calidad en el Desarrollo de Sistemas, de FIUBA, leí el libro The Business of Software, por Michael Cusumano. En este post voy a intentar dar una visión personal del libro Business of Software, incluyendo extractos de lo que yo creo son las ideas o enseñanzas más importantes del libro.

Como el título lo indica, el libro tiene la característica de ser muy orientado a la parte de negocio o económica del software y no tanto al aspecto operativo o conceptual, lo cual le da un toque distintivo frente a otros libros del área. Si bien el autor comparte “buenas prácticas”, según su experiencia, para llevar a cabo el desarrollo de software, estas siempre están acompañadas de ejemplos de empresas reales, con números concretos de cómo estas prácticas impactaron positiva o negativamente en las ganancias de las compañías.

Gran cantidad de ejemplos de experiencias del autor como consultor, permiten contrastar sus propuestas contra casos reales. Esto suma en la credibilidad de sus definiciones y propuestas y al mismo tiempo permite al lector tomar contacto con un resumen casos y experiencias reales de la industria que muchas veces escasean entre los estudiantes.

Ni bien comienza el libro llama la atención la afirmación de que “En la industria del software, es el negocio y no la tecnología el que determina el éxito o el fracaso”. Es común creer que lo difícil en el software es administrar los proyectos, diseñar arquitecturas para resolver problemas complejos con soluciones simples, entre otras cosas. Sin embargo el autor presenta la idea de que como vendemos, cobramos y publicitamos nuestros productos de software es muchas veces más importante que las anteriores problemáticas.

Creo que el capitulo central del libro es el capitulo dos. Una vez introducida la discusión del negocio del software con ejemplos de tres empresas, el autor identifica tres tipos de modelos de negocios que son utilizados por las empresas de software del mundo, los cuales están basado en la estrategia de venta de la empresa.

Primero está el modelo de negocio en base a la venta de licencias de software (“Products Company”). En este modelo una empresa desarrolla un producto de software estándar que después vende al público en general o a las empresas. Este es uno de los modelos de mayor rentabilidad porque una vez que el software ha sido desarrollado toda la venta incremental tiene costo muy bajo, es solo cuestión de “copiar un CD”. Esto último concepto, de grandes ganancias con poco trabajo de replicación se denomina en el libro, economías de escala. Es importante aclarar que solo se puede lograr esta ganancia con un producto fuerte (“best-seller” o “killer app”) de grandes ventas, como puede ser Microsoft Office o Microsoft Windows. La gran desventaja de este modelo es que es muy sensible al mercado, en tiempos económicos favorables las empresas están dispuestas a invertir en software nuevo y las ganancias pueden ser altas. Por el contrario en tiempos desfavorables, las ganancias pueden decaer notablemente por la falta de nuevos clientes.

Por el otro extremo, está el modelo de negocio en base a los contratos de servicios (“Services Companies”). Aquí el objetivo es vender, desde productos a la medida de los clientes hasta mantenimiento o adaptación de sistemas existentes. Este modelo tiene la ventaja que al trabajar con contratos a largo plazo y clientes cautivos, permite generar un flujo de ganancias continuo y ser menos susceptible a las altas y bajas del mercado. La desventaja es que el costo de brindar este servicio es sumamente alto porque es muy intensivo en mano de obra especializada, con lo cual los márgenes de ganancias no son tan altos como en el caso de la orientación a productos.

Finalmente aparecen los modelos híbridos, donde la empresa genera ingresos por venta de licencias de productos y también por venta de servicios para adaptar estos productos a las necesidades de cada cliente. El autor argumenta que a través del tiempo, la mayor parte de las empresas orientadas a productos tienden a evolucionar en empresas hibridas (o hasta en empresas orientadas a servicios) a medida que transcurre el tiempo y los productos que venden se vuelven mucho más corrientes y por ende deben bajar los precios de las licencias (“commodities”). El autor propone a este como el modelo más estable en cuanto a su capacidad de generar ganancias y sobrevivir a las altas y bajas del mercado.

El siguiente diagrama intenta resumir lo explicado anteriormente:

image

Me resultó bastante enriquecedora la sección del libro en la que el autor hace un repaso de la cambiante historia de la industria del software. Es interesante repasar el papel central de IBM en la industria y cómo fue que se realizó la transición desde vender sistemas de plataforma (“system software”) totalmente acoplados (“bundled”) al hardware subyacente, hasta vender software en productos empaquetados.

Creo que el libro está muy orientado a los “software entrepreneurs”, es decir personas que quieren instalar su propio negocio de software y no quedar en bancarrota en el camino. Más precisamente el capitulo cinco, lista una serie de recomendaciones del autor de que decisiones se deben tomar al momento de iniciarse en el negocio del software, cómo conseguir inversiones, como planificar el crecimiento, etc. Y para no dejar cabos sueltos, en el capítulo 6 se analizan 10 casos de “software start-ups” o empresas que se iniciaron en el negocio del software con las que el autor tuvo alguna relación.

Definitivamente el libro no está orientado a programadores, ni tampoco, creo yo, a líderes de proyecto o gerentes de nivel medio de empresas ya instauradas, ya que muy probablemente la problemática que presenta no está asociada a las tareas o inconvenientes diarios de estos profesionales. Esto no quita que el gran valor del contenido del libro, que nos permite “abrir la cabeza” hacia “otra realidad” del software que probablemente muchos de nosotros no vivimos día a día.

Lamentablemente, los números que el autor presenta sobre emprendimientos de software, son sinceramente bastante desalentadores: se cita un estudio en el cual solo 6 empresas de 1 millón que se crean, llegan a ser exitosas y cotizarse públicamente a través de acciones. De todas formas, casos exitosos hay y muchos y nadie dice que convertirse en una empresa multimillonaria como IBM, Microsoft o Accenture, es la única forma de ser exitoso, ya que hay puntos intermedios más modestos que también pueden dar ganancia y reconocimiento a sus fundadores. El autor dice, “no se puede tener éxito sin probar”.

Finalmente, con respecto a mi experiencia personal con la lectura, al iniciar la misma, tuve algunas complicaciones para entender completamente las ideas presentadas por al gran cantidad de términos y expresiones económicas que libro usa. El autor comienza el libro con gran cantidad de ejemplos de los resultados de los balances de compañías de software, con muchos números y porcentajes “duros” de ganancias y pérdidas. A medida que el libro avanza, los términos y ejemplos se van haciendo más familiares y la lectura se volvió más amena.

Debido a que el autor está muy en contacto con la compañía Microsoft (también escribió otro libro más específico sobre Microsoft, llamado “Microsoft Secrets”) constantemente a lo largo del libro se citan ejemplos de prácticas de esta empresa. Me atrajeron bastantes estos ejemplos, que permiten entender más sobre las prácticas, algunas buenas y otras no tanto, que llevaron a Microsoft a ser una de las más grandes, sino la más grande, empresa de software del mundo.

Otro aspecto que me resultó interesante del libro es el análisis de las características particulares industrias del software en cada parte del mundo, haciendo foco en tres o cuatro regiones: India, Japón, Estados Unidos y Europa. El autor en base a sus experiencias como consultor, y a otros trabajos de investigación propios, tiene la capacidad de mostrar las diferencias entre estas regiones tanto desde recursos humanos, como de prácticas especificas de administración de proyectos, etc. Me llamó la atención notablemente, los halagos del autor hacia la industria India del software; si bien conocía del alto desarrollo de la misma, no estaba al tanto de la alta calidad de sus empresas..

Concluyendo, lamentablemente, el libro data del año 2003, lo cual hace que temas como la Web 2.0, las redes sociales o la crisis estadounidense de 2008-2009, que tuvo fuerte impacto en la industria del software, no estén dentro de los ejemplos cubiertos por el libro. Sería muy interesante tener no solo la visión del autor sobre estos últimos años de la industria del software, sino también números concretos de la evolución (¿o porque no involución?) de la industria en este último período. Otra desventaja, también probablemente debida al año de publicación del libro, es que dentro de las empresas y casos de éxito de la industria analizados, en ningún momento se nombra a Google.

Glosario y Referencias

Estos son algunos términos o referencias particulares que fueron apareciendo a lo largo del libro que no conocía y me pareció interesante saber más al respecto:

  • Crossing the chasm: Siendo “chasm” algo así como cañón o risco, es un término basado en un libro de Geoffrey A. Moore y relacionado al ciclo de adopción de nuevas tecnologías por él mercado. Implica que hay un salto importante entre los clientes con preponderancia a adoptar nuevas tecnologías (Early Adopters) y el mercado masivo (Early Majority).
  • Whole product solutions: En marketing, consiste en un producto genérico (core product) rodeado de una serie de aditamentos, muchas veces prescindibles, que impulsan a los clientes a comprar el producto. En nuestro caso, el “core product” vendría a ser el producto de software y los aditamentos, la customización y soporte necesarios para adaptar el producto a un cliente en particular.
  • Catch-22: O Trampa 22, es una sátira antibelicista de historia ficción escrita por Joseph Heller y publicada en 1961. En este libro el autor presenta una paradoja circular. Se narra la historia de un piloto estadounidense en la Segunda Guerra Mundial que trata de evitar entrar en combate haciéndose pasar por loco. Paradójicamente, el artículo 22 del reglamento establece que nadie en su sano juicio querría pilotar un bombardero en semejantes circunstancias, de modo que su alegación demuestra en realidad que está cuerdo y que debe seguir pilotando.
  • Porter’s five forces: El Análisis Porter de las cinco fuerzas es un modelo estratégico elaborado por el economista y profesor de la Harvard Business School Michael Porter en 1979. Las 5 Fuerzas de Porter es un modelo que permite analizar cualquier industria en términos de rentabilidad. El autor nombre esta teoría como una base, entre otras, para su análisis del negocio del software. Las 5 fuerzas son:
    • Poder de negociación de los Compradores o Clientes
    • Poder de negociación de los Proveedores o Vendedores
    • Amenaza de nuevos entrantes
    • Amenaza de productos sustitutivos
    • Rivalidad entre los competidores
  • Venture Capital: El capital riesgo consiste en realizar inversiones a empresas nuevas de alto riesgo en cuanto al retorno de la inversión, que al mismo tiempo pueden generar altas ganancias en el caso de éxito.
  • IPO (Initial Public Offering): Cuando una empresa pone sus acciones a la venta publicamente por primera vez. El objectivo es incorporar capital a la empresa para posibilitar un mayor crecimiento.
  • Mosaic Web Browser: Mosaic es considerado el primer navegador Web. Su construcción fue dirigida por el fundador de Netscape, Marc Andreessen.
  • Unbundling: El autor utiliza este término denominando la separación entre vender software solo (“unbundled”) y venderlo acoplado al hardware subyacente (“bundled”).
Advertisements

Posted in Business, FIUBA, Libros | 2 Comments »

Writing User Stories

Posted by sebastiandurandeu on March 26, 2010

El objetivo de este post es tener una referencia rápida de que cosas tener en cuenta para escribir User Stories (en inglés):

  • User Stories General Guidelines
    • Each story must be written in the language of the business, not in technical jargon. They should be comprehensible by both the developers as well as the customer team.
    • Each user story represents a discrete piece of functionality; that is, something a user would be likely to do in a single setting.
    • A user story is short and concrete, something like:

      ”A user can view detailed information about a company that has posted a job.”
      More details about the story can be written in the form of user acceptance tests, that is reminders of how to test a story, and attached to the story. For example:

    • Test with empty job description.
      Test with really long job description.

    • Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work.
    • To create good stories we focus on six attributes. A good story is (INVEST):
      • Independent
      • Negotiable
      • Valuable to users or customers
      • Estimatable
      • Small
      • Testable
    • Ideally, stories are independent from one another. This isn’t always possible but to the extent it is, stories should be written so that they can be developed in any order.
    • The details of a story are negotiated between the user and the developers.
    • Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories.
    • Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer.
    • One of the best ways to annotate a story is to write test cases for the story.
    • If they are too big, compound and complex stories may be split into multiple smaller stories.
    • If they are too small, multiple tiny stories may be combined into one bigger story.
    • Stories need to be testable.
  • User Story Size
      1. Agile Theme. A set of user stories related.
      2. Agile Epic: Large user story. For a feature that you want eventually but that isn’t important right now, you can first write a large story (an epic). When you’re ready to add that story into the system you can refine it by ripping up the epic and replacing it with smaller stories that will be easier to work with.
      3. Agile User Story
      4. Agile Task
    • It’s good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers.
    • User Stories categories by size:
  • User Story Roles
    • Each story should be written from a perspective of a user role. As part of the process of writing stories, you should identify all the user roles who will interact with the software.
    • A user role is a collection of defining attributes that characterize a population of users and their intended interactions with the system.
  • User Stories Estimations Techniques
    • Expert Opinion
    • Analogy
    • Disaggregation
    • Planning Poker: Mix of three. Based on the Delphi method.
  • User Stories Estimation Scales
    • Fibonacci (1,2,3,5 + 8 ) –> Story Point Estimation
    • Power of 2 (1,2,4 + 8 )
    • T-shirt Sizing –> For estimating Epics

Using Points makes the unit of estimation abstract, which makes it easier to commit to, and easier to adjust your commitments to. Points are an abstract number. They do not convert to a unit of time. They are simply a *relative* indication of size.

The non-linear sequence work well because they reflect the greater uncertainty associated with estimates for larger units of work.

  • Team Velocity
    • The amount of score completed by the team after one iteration.
    • The team’s first estimate of velocity will be wrong because there’s no way to know velocity in advance.

References:

Posted in Project Management, SCRUM | Leave a Comment »

Introduccción a “Identity”

Posted by sebastiandurandeu on March 25, 2010

Necesitamos encarar un proyecto relacionado con “identity” para la facultad (el porque lo dejamos para otro momento). Aún no sabemos especificamente que problematica queremos atacar dentro de esta gran bolsa, pero creemos estar seguros que el tema central debe ser éste. Para introducirme en el tema decidimos ir en busca de información introductoria y esto es lo que encontramos (tanto en inglés como en castellano):

Problablemente la cosa venga por el lado de Federated Identity. Claramente estamos medio perdidos aún 😛 , pero mejoraremos…

Posted in Uncategorized | Leave a Comment »

Simulación – FIUBA

Posted by sebastiandurandeu on June 28, 2009

Comparto la “referencia” del lenguaje GPSS que use para la materia Simulación (75.26).

Se puede bajar desde:
https://sebastiandurandeu.files.wordpress.com/2008/01/referenciagpss.doc

La versión original en la que esta basado es Cartilla.doc (Grupo Yahoo sistemas_fi_uba).

Posted in FIUBA, GPSS | Leave a Comment »

Analisis de la Información – FIUBA

Posted by sebastiandurandeu on August 7, 2008

Esto es una resumen de varios temas de la materia Analisis de la Información (75.09) de la Facultad de Ingeniería de la UBA.

UML – Modelo Estructural

Modeling

A good model includes those elements that have broad effect and omits those minor elements that are not relevant to the given level of abstraction.

We build models so that we can better understand the system we are developing:

  • Models help us to visualize a system as it is or as we want it to be.
  • Models permit us to specify the structure or behavior of a system.
  • Models give us a template that guides us in constructing a system.
  • Models document the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

Modeling allow us to focus on only one aspect at a time –> “Divide and conquer”

All models simplify reality; the trick is to be sure that your simplifications don’t mask any important details.

UML: using a common language for software modeling.

Classes Responsibilities

You don’t want any one class to be too big or too small. Each class should do one thing well.

  • If you abstract classes that are too big, you’ll find that your models are hard to change and are not very reusable.
  • If you abstract classes that are too small, you’ll end up with many more abstractions than you can reasonably manage or understand.

Diagrama de clases

  • No esta mal agregar un identificador a las clases.
  • El rombo de asociación o agregación va en el contenedor.
  • Composición: “Es parte de”. Si elimino el contenedor no tiene sentido las partes.
  • Responsabilidad de una clase: Es un contrato o una obligación que debe cumplir una clase. Una clase debe tener una responsabilidad pero no muchas.

UML – Modelo Dinámico

Diagrama de Colaboración = Communication Diagram

Sequence Diagrams + Communication Diagrams = Interaction Diagrams

Interaction: An interaction goes further by introducing a dynamic sequence of messages that may pass along the links that connect these objects.

Diagrama de Secuencia

En el diagrama de secuencia, sobre la flecha va el nombre del método del objeto destinatario. Si A le manda un mensaje a B sobre la flecha va B.Mensaje().

La línea de vida se corta si el objeto se destruye.

The focus of control is a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.

Diagrama de Secuencia vs Diagrama de Colaboración

Because they both derive from the same information in the UML’s metamodel, sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information, as you can see in the previous two figures, which are semantically equivalent.

  • To model flows of control by time ordering: Here you’ll use sequence diagrams.
  • To model flows of control by organization: Here you’ll use communication diagrams. Modeling a flow of control by organization emphasizes the structural relationships among the instances in the interaction, along which messages may be passed.

Lo que sigue es un ejemplo de loop (pide el password de una a tres veces) , de ejecución opcional (si el password fue valido) y de ejecución en paralelo (par). Parallel really means that two actions are uncoordinated and can happen in any order.

image

Sub- Modelos de UML

  • Modelo de Casos de Uso (Dinámico):
    • Diagrama de casos de uso: Organiza los comportamientos del sistema. Representa un conjunto de casos de uso y actores y sus relaciones.
  • Modelo de Objetos (estático) :
    • Diagrama de clases:
    • Diagrama de objetos: Modela las instancias de los elementos contenidos en el diagrama de clases. Muestra un conjunto de objetos y sus relaciones en un momento concreto.
  • Modelo de Interacción entre Objetos:
    • Diagrama de secuencia: Destaca el flujo de interacción entre objetos. Un diagrama de actividades muestra las operaciones que se pasan entre los objetos. Se pueden usar como diagramas de flujo para modelas operaciones.
    • Diagrama de colaboración:
  • Modelo de Estado de Objetos (Dinámico):
    • Diagrama de transición de estado de objetos: Representa una máquina de estados. Muestra las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos.
  • Modelos de Negocio (Dinámico): Muestra el flujo de actividades en un sistema.
    • Diagrama de actividades: Destaca el flujo de control de actividades.
  • Modelo de Componentes (Estático): Muestra la organización y las dependencias entre un conjunto de componentes (Un componente = uno o mas clases). Los componentes son las cosas físicas que residen en un nodo: ejecutables, bibliotecas, tablas, archivos y documentos.
  • Modelos de Despliegue (Estático): Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Un nodo corre uno o mas componentes.

Use Cases

Writing Effective Use Cases (Resumen Libro)

A use case need not be the best to be useful.

A use case captures a contract between the stakeholders of a system about its behaviour.

A well-written use case is easy to read. It consists of senteces written in only one grammatical form -a simple action step- in which an actor achieves a result or passes information to another actor. Learning to read a use case should not take more than a few minutes.

Business process people write business use cases to describe the operation of their business, while a software development team writes system use cases for their requirements.

A use case valid in one project might not be valid in another project.

Use cases reveal user goal the system will support.

In one use case:

  • All the interaction relate to the same goal of the same primary actor.
  • The use case starts at the triggering event and continues until de goal is delivered or abandoned, and the system completes its responsibilities with respect to the interaction.

A step in a use case can be drilled down to another use case.

Use case brief: Is a two-to-six sentence description of use case behavior, mentioning the actors, the goals an only the most significant activity and failures.

An actor might be a person, a company or organization, a computer program or a computer system- hardware, software or both.

Relations between use cases:

  • <<include>>: One use case refers or calls another.
  • <<extends>: Create extension use cases only when you need to, because they are harder for people to understand and mantain. Two Situations:
      • Many asynchronous or interrupting services the user might use, which should not disturb the use case. Example:Edit document –> Check Spelling –> Change template–> Find synonym
      • Writting additions to locked requirements.

Supporting Actors (or secondary actors): A supporting actor in a use case is an external actor that provides a services to the system under design. These are sets of actors that support the use cases provided by the system and those that support the system itself.

Actions of supporting actors involve to provide additional information or take some decisions.

An actor can be primary in one use case and supporting in another.

Primary actor: The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction. It is both necessary and correct that we should concentrate our efforts primarily on these actors and the users that will take on these roles.

When writing use cases: KEEP THE GOAL IN MIND.

Common mistakes:

– Avoid a use case where every statement is accomplished by the actor

– Customer enters card and PIN

– customer enters “Withdrawal” and amount.

– Customer takes cash, card and receipt.

– Avoid detailing user interfaces in the use case.

– Remember every use case must show the primary actor actions.

– Remember always naming who is doing the action, avoiding passive voice.

Use Cases Modeling (Resumen Libro)

We don’t consider the operating system, database, or other utilities as actors. Although we certainly make use of their capabilities, we are not required by the system to use them in specific ways at specific times.

A use case is focused on what the system must do, whereas code is an expression of how the system will do those things.

Prototypes: As the saying goes, a picture is worth a thousand words. If that’s true, a prototype is invaluable. Use prototypes to describe the user interface, leaving the use cases to describe what happens behind the screens.

The whole point of a use case is to capture a description of something that the system must do. It is an expression of a desired behavior of the system. The system must behave that way no matter how it is designed and implemented.

Make sure that each use case provides the user of the system with something of value.

Glossary: Use cases often contain a lot of information that can be better presented in other ways. Using a glossary of terms is one way to present necessary information that can otherwise be distracting to the reader.

Every use case has two exits: succed or fail.

Sub-flujos / Flujos Alternativos

  • “Named” Subflows: Sections that perform important behaviors but that are not essential to understanding the basic flow of events. Ej. Perform Authenticate Customer.
  • “Alternative” flows: Flows of events that occur when something other than the normal course of events has occurred.

Rational Unified Process

Esto es un resumen de todo lo que se da en la teórica sobre RUP.

Mejores prácticas para el desarrollo de software.

  • Proceso iterativo e incremental.
  • Dirigido por casos de uso
  • Arquitectura basada en componentes (reusabilidad).
  • Modelización visual
  • Gestión del cambio
  • Verificación de calidad

Contribución del RUP a las buenas prácticas

Iterativo e Incremental

  • 1 ciclo compuesto de distintas fases:
    • Inicio
    • Elaboración
    • Construcción
    • Transición
  • Cada una de estas fases tiene mas de una iteración. En cada una de las iteraciones hay diferentes disciplinas en las que se gasta mas o menos esfuerzo dependiendo de la fase en la que se esta.
    • Captura de requisitos
    • Análisis
    • Diseño
    • Implantación
    • Pruebas y Despliegue
  • Además de esto hay componentes de soporte del proceso:
    • Gestión de cambios: Trackear requerimientos de cambio. Versionado.
    • Administración de proyecto: Risk Managment. Monitoring process.
    • Gestión de ambiente: Preparación de ambiente de desarrollo (procesos y herramientas necesarios para el desarrollo).

Matriz de Esfuezo

Define el esfuerzo dedicado a cada disciplina en cada fase.

clip_image001[4]

Dirigido por casos de uso

Los casos de uso se utilizan a lo largo de todo el proceso. Los casos de uso son una buena forma de capturar requerimientos y guiar la implementación y las pruebas. La arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

clip_image002

  • En la captura de requisitos: Los casos de uso se unan para capturar y validar los requerimientos.
  • En análisis y diseño y en implantación: Se implementan los casos de uso.
  • En las pruebas: Se realizan las pruebas que verifiquen el cumplimiento de los casos de uso.

Arquitectura basada en componentes

Se trata de diseñar una arquitectura base ejecutable en forma temprana.

Arquitectura base ejecutable

  • Flexible
  • Fácil de modificar
  • Promover la reutilización de componentes

RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

Modelización visual

Utilización intensiva de UML.

Gestión del Cambio

Los cambios pueden ser de requisitos o de funcionalidades. Los cambios son inevitables.

Como gestionar cambios?

  • Evaluación: Son realmente necesarios? Cual es su impacto?
  • Rastreo y monitoreo.

RUP provee herramientas para controlar, rastrear y monitorizar los cambios dentro del proceso de desarrollo.

Verificación de la calidad

RUP provee herramientas para planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen la calidad del desarrollo. De esta forma vemos que la calidad forma parte del proceso de desarrollo y no es responsabilidad de un grupo separado.

  • Funcionalidad
  • Rendimiento
  • Confiabilidad.

Matriz de Hitos y Productos de Cada Fase

clip_image003

clip_image004

Caso de Negocio: The Business Case provides the necessary information from a business standpoint to determine whether or not this project is worth investing in. For a commercial software product, the Business Case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the Elaboration phase, when the scope and plan are defined with more accuracy.

RUP como Proceso de Desarrollo de software

Define:

  • Quien hace que cosa?
  • Que hace?
  • Como lo hace?
  • Cuando lo hace?

Sobre el Quien RUP define tres tipos de elementos:

  • Trabajador: define el comportamiento y las responsabilidades de un individuo.
  • Actividad: A unit of work in the RUP that a role may be asked to perform. An activity may be decomposed in steps. Activities produce or modify artifacts.
  • Artefacto: Artifacts are either final or intermediate work products that are produced and used during a project. Artifacts are used to capture and convey project information.

clip_image001[6]

  • Trabajador (Worker) :
    • Comportamiento –> Rol: A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.
      • Analista
      • Diseñador
      • Ing. Pruebas
    • Responsabilidad: Actividad que va a realizar la persona, que será responsable de una serie de artefactos.
  • Actividad: Es una unidad de trabajo que se asigna a un determinado trabajador. No debería durar menos de dos horas y mas de veinte dias. Debe involucrar un solo trabajador y pocos artefactos. Ejemplos:
    • Planificar una iteración
    • Encontrar actores y casos de uso
    • Ejecutar pruebas unitarias
    • Ejecutar pruebas de performance
    • Diseñar casos de uso
  • Artefactos: Elementos de información producidos, modificados o utilizados durante el proceso. Son el resultado de actividades y utilizados además como inputs a otras actividades. Ejemplos:
    • Modelos: Modelo de caso de uso. Modelo de objetos.
    • Elemento de un modelo: Caso de uso. Clase.
    • Documentos: Caso de negocio. Documento de arquitectura del sistema.
    • En etapa de construcción: Código Fuente. Código ejecutable.

Matriz de Asignaciones

clip_image002[4]

Análisis Estructurado

El modelo esencial supone que se tiene disponible una tecnología perfecta y que se puede obtener fácilmente. (Yourdon p.358) Un modelo se tiene que componer de gráficos y documentos de texto. Uno o mas gáficos debieran ser el documento primario al que se dirige el usuario para poder entender el sistema; los documentos textuales debieran servir de material de referencia para consultar en caso de necesidad (Yourdon p.152)

Modelo Ambiental

Objetivo

Ejemplo:

clip_image001

Diagrama de Contexto

Muestra:

  • Las personas, organizaciones y sistemas con los que se comunica el sistema.
  • Los datos que el sistema recibe del mundo exterior.
  • Los datos que se envían al mundo exterior.
  • Los almacenes de datos externos al sistema.
  • A veces conviene dibujar a los objetos externos mas de una vez.

Lista de Eventos

En todo evento va a ocurrir un estímulo y una respuesta.

Eventos

  • Externos: Entidad Externa + Verbo + Objeto
  • Temporales
    • Tipo 1: Período + Verbo + Objeto (Nadie espera lo que se emite)
    • Tipo 2: Período + Ent. Externa + Verbo + Objeto (La entidad externa solicita el objeto)

Lista de Estímulos y Respuestas

  • Los almacenamientos van en plural.
  • Usar:
    • Mensualmente vs Todos los meses

    Modelo de Comportamiento

    Modelo de Procesos

  • DFD: Modelo las funciones que lleva a cabo un sistema. Evitar los verbos: Hacer, Manejar y Procesar. Son verbos muy genéricos.
  • Diagrama de Transición de estados: Modela el comportamiento dependiente del tiempo de un sistema.

    Modelo de Datos

  • Diccionario de datos: Un listado organizado de todos los datos pertenecientes al sistema para tener un entendimiento común de:

    • Todas las entradas, salidas y almacenes y cálculos intermedios del sistema.
    • Relaciones entre almacenes del DER.
    • () –> Se usa para un dato opcional.

    DER: Describe la distribución de datos almacenados en un sistema.

    • Los tipos de objeto van en singular.
    • Puede haber relaciones entre el mismo tipo de objeto (Relación reflexiva. Ej. Curso correlativo de curso).
    • Cada instancia tiene que poder identificarse en forma univoca.
    • La relación entre tipo de datos es algo que debe ser recordado por el sistema.
    • Objetos no instanciables (unicos en todo el sistema) no van en el DER.
    • Herencia:

    clip_image002[1]

    El nombre de una asociación solo va si la asociación es pura.

    Bibliografia

    Posted in FIUBA, RUP, UML | 2 Comments »

    ‘WORK EXPANDS SO AS TO FILL THE TIME AVAILABLE FOR ITS COMPLETION’

    Posted by sebastiandurandeu on July 11, 2008

    This is also known as the Parkinson’s Law, written by Prof. Cyril Northcote Parkinson in an article from 1957.

    “General recognition of this fact is shown in the proverbial phrase ‘It is the busiest man who has time to spare.’ Thus, an elderly lady of leisure can spend the entire day in writing and dispatching a postcard to her niece at Bognor Regis. An hour will be spent finding the postcard, another in hunting for spectacles, half an hour in a search for the address, an hour and a quarter in composition, and twenty minutes in deciding whether or not to take an umbrella when going to the pillar box in the next street. The total effort that would occupy a busy man for three minutes all told may in this fashion leave another person prostrate after a day of doubt, anxiety, and toil.

    […]”

    Extracted from the Parkinson’s article.

    “Parkinson’s Law dictates that a task will swell in (perceived) importance and complexity in relation to the time allotted for its completion. It is the magic of the imminent deadline. If I give you 24 hours to complete a project, the time pressure forces you to focus on execution, and you have no choice but to do only the bare essentials.

    If I give you a week to complete the same task, it’s six days of making a mountain out of a molehill. If I give you two months, God forbid, it becomes a mental monster. The end product of the shorter deadline is almost inevitably of equal or higher quality due to greater focus.
    This presents a very curious phenomenon. There are two synergistic approaches for increasing productivity that are inversions of one another:
    1.) Limit tasks to the important to shorten work time. (80/20)
    2.) Shorten work time to limit tasks to the important. (Parkinson’s Law).
    The best solution is to use both together: Identify the few critical tasks that contribute most to income and schedule them with very short and clear deadlines.”

    Extracted from Book Excerpt: The 4 Hour Workweek.

    Summarizing: “If you have only one letter to write, it will take all day to do it. If you have twenty letters to write, you’ll get them done in one day“.

    This fact can be also stated as a Gas Principle, where everything expands up to fill every available space.

    Posted in Uncategorized | Leave a Comment »

    Síndrome de los “Veintipico”

    Posted by sebastiandurandeu on May 21, 2008

    Esto no lo escribí yo, me lo mando por mail un amigo (Gracias Maro!), pero creo que esta muy bueno. Ahí va:

    Le llaman la ‘crisis del cuarto de vida’.

    Te empiezas a sentir inseguro y te preguntas dónde estarás en un año o dos, pero luego te asustas al darte cuenta que apenas sabes donde estás ahora.

    Te empiezas a dar cuenta de que hay un montón de cosas sobre ti mismo de las que no sabías y que quizás no te gusten.

    Te empiezas a dar cuenta de que tu círculo de amigos es más pequeño que hace unos años atrás. Te das cuenta de que cada vez es más difícil ver a tus amigos y coordinar horarios por diferentes cuestiones: trabajo, estudio, pareja, etc. Y cada vez disfrutas más de esa cervecita que sirve como excusa para charlar un rato. Las multitudes ya no son ‘tan divertidas’, hasta a veces te incomodan.

    Y extrañas la comodidad de la escuela, de los grupos, de socializar con la misma gente de forma constante.
    Pero te empiezas a dar cuenta que mientras algunos eran verdaderos amigos, otros no eran tan especiales después de todo.

    Te empiezas a dar cuenta de que algunas personas son egoístas y que, a lo mejor, esos amigos que creías cercanos no son exactamente las mejores personas que has conocido y que la gente con las que has perdido contacto resultan ser amigos de los más importantes para ti.

    Ríes con más ganas, pero lloras con menos lágrimas, y con más dolor.

    Te rompen el corazón y te preguntas como esa persona que amaste tanto te pudo hacer tanto mal. O quizás te acuestes por las noches y te preguntes por qué no puedes conocer a alguien lo suficientemente interesante como para querer conocerlo mejor.

    Pareciera como si todos los que conoces ya llevan años de novios y algunos empiezan a casarse. Quizás tú también amas realmente a alguien, pero simplemente no estás seguro si te sientes preparado para comprometerte por el resto de tu vida.

    Atraviesas por las mismas emociones y preguntas una y otra vez, y hablas con tus amigos sobre los mismos temas porque no terminas de tomar una decisión.

    Los ligues y las citas de una noche te empiezan a parecer baratos, y emborracharte y actuar como un idiota empieza a parecerte verdaderamente estúpido.

    Salir tres veces por fin de semana resulta agotador y significa mucho dinero.

    Miras tu trabajo y quizás no estés ni un poco cerca de lo que pensabas que estarías haciendo. O quizás estés buscando algún trabajo y piensas que tienes que comenzar desde abajo y te da un poco de miedo.

    Tratas día a día de empezar a entenderte a ti mismo, sobre lo que quieres y lo que no.

    Tus opiniones se vuelven más fuertes. Ves lo que los demás están haciendo y te encuentras a ti mismo juzgando un poco más de lo usual porque de repente tienes ciertos lazos en tu vida y adicionas cosas a tu lista de lo que es aceptable y de lo que no lo es.

    A veces te sientes genial e invencible, y otras, solo, con miedo y confundido.

    De repente tratas de aferrarte al pasado, pero te das cuenta de que el pasado cada vez se aleja más y que no hay otra opción que seguir avanzando.

    Te preocupas por el futuro, préstamos, dinero, etc. y por hacer una vida para ti. Y mientras ganar la carrera sería grandioso, ahora tan solo quisieras estar compitiendo en ella.

    Lo que puede que no te des cuenta es que todos los que estamos leyendo esto nos identificamos con ello. Todos nosotros tenemos ‘veintitantos’ y nos gustaría volver a los 15-16 algunas veces. Parece ser un lugar inestable, un camino en tránsito, un desbarajuste en la cabeza… pero todos dicen que es la mejor época de nuestras vidas y no tenemos que desaprovecharla por culpa de nuestros miedos. Dicen que estos tiempos son los cimientos de nuestro futuro.
    Parece que fue ayer que teníamos 16… ¿Entonces mañana tendremos 30? ¿Así de rápido? Hagamos valer nuestro tiempo. Que no se nos pase!
    La vida no se mide por las veces que respiras, sino por aquellos momentos que te dejan sin aliento.

    Mostrale esto a tus amigos de veintitantos. Quizá le ayude a alguien a darse cuenta que no esta solo entre tanta confusión.

    Posted in Uncategorized | Leave a Comment »

    Sistemas Operativos (75.08) – Trabajo Práctico – 2do Cuat 2008

    Posted by sebastiandurandeu on May 1, 2008

    Este es el trabajo práctico que hicimos con mi grupo para la materia Sistemas Operativos de FIUBA. EL TP esta hecho en Bash scripting y PERL.

    Se puede descargar de:
    http://www.divshare.com/download/4392050-6ba

    La idea del TP es mas o menos la siguiente:

    La AFIP (Agencia Federal de Ingresos Públicos) brinda a los contribuyentes (según Resolución General 1361) inscriptos en el IVA (Impuesto al Valor Agregado) la facilidad de almacenar en sus servidores el duplicado electrónico de comprobantes que intervienen en la liquidación de ese impuesto

    Los contribuyentes que soliciten este servicio son habilitados y a partir de esa fecha deben enviar periódicamente  a la AFIP los archivos con la información de los comprobantes.

    La AFIP recibe los archivos, los valida, genera una clave de autorización electrónica (CAE) y los almacena.

    Una vez efectuado este proceso los contribuyentes pueden acceder al sitio correspondiente de la AFIP para consultar los comprobantes, emitir copia fiel, etc.

    En este TP se pide desarrollar parte de este trabajo, haciendo foco solo en el procesamiento de duplicados de Compras.

    Para ello se deberá:

    Desarrollar usando shell script los siguientes comandos:

    • Comando de instalación (InstalC): Este instalable debe ser del tipo self-extractable. Esto significa que será un shell que realice todas las tareas de la instalación normales (ej.: crear directorios) pero que también genere, sin recurrir a archivos externos, los archivos de datos, los comandos, etc.,  a partir de la información que contiene él mismo.
    • Comando de Inicialización de Ambiente (IniciaC): Este comando es el primero en orden de ejecución. No graba en el Archivo de Log y se invoca manualmente. Su propósito es preparar el ambiente necesario para la correcta ejecución del TP, como por ejemplo: Setear adecuadamente el Path y otras variables de ambiente, adecuar permisos, verificar espacio, etc.
    • Comando de Recepción de Archivos de Compras (RecibeC): Este comando es el segundo en orden de ejecución. Graba un archivo de log llamado recibec.log. Se invoca en forma manual o a través del comando IniciaC. El propósito de este comando es detectar la llegada de archivos al directorio $grupo/arribos, moverlos al directorio correspondiente, dormir un tiempo x y volver a ejecutarse. 
    • Comando de Validación de Comprobantes de Compras (ValidCo): Este comando es el tercero en orden de ejecución. Graba un archivo de log llamado validco.log. Se invoca en forma manual o a través del comando RecibeC. El propósito de este comando es formatear los registros recibidos y validarlos a fin de poder almacenarlos con la estructura adecuada en el directorio correspondiente.
    • Comando de Consultas de Comprobantes – PERL (ConsulC): Este comando es el cuarto en orden de ejecución. No graba un archivo de log. Se invoca en forma manual con las opciones y parámetros adecuados. El propósito de este comando es obtener algunos listados que permitan conocer la recaudación probable por período. Siempre se deben mostrar los resultados por pantalla, pero si se invoca al comando con la opción –w, se deben grabar los resultados en un archivo (en el directorio $grupo/consultas).
    • Comando Auxiliar para la escritura de los archivos de log que graban los comandos: RecibeC y ValidCo – PERL o BASH (GrabaL) 

     La otra gente del grupo:

    • Mariana Gambande
    • Leandro Ferrigno
    • Alejandro Lamprópulos
    • Czelada Esteban

    Posted in Uncategorized | Leave a Comment »

    101 Great Computer Programming Quotes

    Posted by sebastiandurandeu on March 29, 2008

    A really good article at http://www.devtopics.com/101-great-computer-programming-quotes/.

    A quick sample:

    •  “That’s what’s cool about working with computers.  They don’t argue, they remember everything, and they don’t drink all your beer.”
      (Paul Leary)
    • “Never trust a computer you can’t throw out a window.”
      (Steve Wozniak)
    • “It is not about bits, bytes and protocols, but profits, losses and margins.”
      (Lou Gerstner)
    • “Don’t worry if it doesn’t work right.  If everything did, you’d be out of a job.”
      (Mosher’s Law of Software Engineering)
    • “The best thing about a boolean is even if you are wrong, you are only off by a bit.”
      (Anonymous)
    • “C++ : Where friends have access to your private members.”
      (Gavin Russell Baker)
    • “Software is like sex: It’s better when it’s free.”
      (Linus Torvalds)
    • “If McDonalds were run like a software company, one out of every hundred Big Macs would give you food poisoning, and the response would be, ‘We’re sorry, here’s a coupon for two more.’ ”
      (Mark Minasi)
    • “Programming is like sex: one mistake and you’re providing support for a lifetime.”
      (Michael Sinz)
    • “To err is human, but to really foul things up you need a computer.”
      (Paul Ehrlich)

    Posted in Uncategorized | Leave a Comment »

    Einstein Quotes

    Posted by sebastiandurandeu on March 8, 2008

    “Make everything as simple as possible, but not simpler.”. This is also know as the KISS principle in desing that states that complexity should always be avoided.
    At the same time, Antoine de Saint Exupéry said “It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away”.

    “Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.”

    “The significant problems we face cannot be solved at the same level of thinking we were at when we created them.”

    “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.”

    “If we knew what it was we were doing, it would not be called research, would it?”

    “The secret to creativity is knowing how to hide your sources.”

    “Do not worry about your difficulties in Mathematics. I can assure you mine are still greater.”

    “If the facts don’t fit the theory, change the facts.”

    I’ve found most of these on: http://www.quotedb.com/  and http://www.brainyquote.com/.

    Posted in Frases | Leave a Comment »