Visualizing the state of projects using geometric figures (follow-up)

Building a project status spectrum

In the previous post entitled "Visualizing the state of projects using geometric figures", it's possible to build a status spectrum for on-going projects with respect to time.

Framework:
  • Define a set of variables: scope, time, budget, priority...
  • Choose a chart in which to display the variables. The chart has to represent all variables.
  • Each variable has a label and a value associate with it.
  • For homogeneity reasons, each value should normalized in order to fit a predefined range.
In this context the only fixed elements are the chart and labels of the variables. All the other elements vary with time.

T(1):Chart(1), T(2):Chart(2), T(3):Chart(3),...,T(n):Chart(n)

The "SUM" of all charts on the same timeline is the spectrum.
Cases:
  1. A predefined finite timeline and variables represents the time frame of a project.
  2. An infinite timeline with finite variable represents an on-going project.
  3. An infinite timeline with infinite variables represents uncertainty.
  4. ...
To be continued ...

    Sizing Software Applications

    Applications are software programs designed to perform functions for users. They use operating system services and other supporting programs to perform a designated function.
    Before developing an application, it would be nice to have an estimate of its size in terms of effort and/or costs.

    Applications can be big and complex or small and simple. An application that needs to interface and interact with users can be characterized by a certain number of elements, such as wireframes, use cases, business rules, data tables, reports, and correspondences. The size of an application can be determined by the number of these elements. The table below describes a hypothetical example.

    Application
    Number of Elements
    Wireframes
    Use Cases
    Business Rules
    Data Tables
    Reports
    Correspondences
    10
    50
    90
    100
    10
    15
    Estimated effort to develop one element of simple complexity level in man-days
    3
    5
    3
    3
    2
    2
    Development Effort (man-days)
    30
    250
    270
    300
    20
    30
    Estimated effort to capture one element during the analysis phase of simple complexity level in man-days
    3
    3
    3
    3
    1
    1
    Analysis Effort (man-days)
    30
    150
    270
    300
    10
    15
    Total Effort (man-days)
    60
    400
    540
    600
    30
    45

    Legend of elements:
    -Wireframes are user interfaces and it’s the way the user communicates with the application.
    -Use Cases describe how a user interacts with the application in a procedural way.
    -Business Rules govern the flow of procedures and data.
    -Data Tables are the data required for the application to perform its function.
    -Reports are printable information.
    -Correspondences can be notes, messages, and emails.

    N.B.- The numbers in the table above do not refer to any industry standard, they are all hypothetical numbers just for calculation and illustration purposes.

    By introducing hypothetical unit rates per day it’s possible to calculate the relative and total costs.

    -Development unit rate per day = $300 
    -Analysis unit rate per day = $500

    Putting data in table format:

    Costs
    Total Effort Development in man-days
    900
    Developers rate per day in $
    300
    Developers Cost in $
    270000
    Total Effort Analysis in man-days
    775
    Analyst rate per day in $
    500
    Analysts Cost in $
    387500
    Total Cost in $
    657500

    All data in this example is hypothetical. For better accuracy, it’s possible to add more variables and factors to this approach.