Data Security




If computer A needs to communicate with computer F in confidentiality, then any data exchanged between A and F over the network has to be encrypted. Hence, in case the data gets intercepted over the network, no one should be able to understand the conversation between A and F.

One way to implement confidentiality between n-parties is with the use of encryption based on symmetric or asymmetric algorithms.

Symmetric system: A symmetric system uses one key for both encryption and decryption.

K= Key; E = Encryption Function; D= Decryption Function; X= Data in clear; Y= Encrypted data

A encrypts X and sends it to F as Y: {A [Y= EK(X)]} = A{Y} is sent to F
F receives and decrypts Y in order to get the original data X in clear: {F[X=DK(Y)]} = F{X}

Asymmetric system: An asymmetric system uses two keys, one public and one private.

X= Data in clear; Y= Encrypted data; PBKA= A’s public key; PRKA= A’s private key (only known to A); PBKF= F’s public key; PRKF= F’s private key (only known to F); E = Encryption Function; D= Decryption Function

A encrypts X with F’s public key and sends it F as Y: {A[Y=EPBKF(X)]} = A{Y} is sent to F
F receives and decrypts Y with F’s private key in order to the original data X in clear: 
{F[X=DPRKF(Y)]} = F{X}

In an asymmetric system, switching the use of keys would give electronic signature or authenticity.



(See Wikipedia for an articulated meaning of this topic)

Re-thinking Blog Contents


I am re-thinking blog contents. Art and Science is a concept for adding values to anything you do. The science part is the learnings and methods acquired through studies and work and the art part is the inborn creativity that is inherent and singular to each individual. This is what makes things unique. For example, if two projects have the same identical requirements, the outcome of each project, most likely, will be unique due to people's differences and diversities.  

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.

    Variance At Completion

    In project management a variance is the difference between a planned cost and the actual cost incurred and, normally, this leads to corrective actions. A more general definition of Variance Analysis can be found in Wikipedia and in many other web sites that specialize in this topic.

    Variance Analysis
    
    At Time Now:

    Ei = Initial Estimate (Planned or Estimated Budget)
    Actuals = A = Actual amount incurred
    Et-c = Estimate To Complete
    Ea-c = Estimate At Completion = A + Et-c
    Va-c = Variance At Completion = Ei  - Ea-c
    At New Time (Time Now + T):
    If the variance is high (too much error or discrepancy), then it will be appropriate to assign Ea-c as the new Ei. 

    Hence,
    Ei (new time) = Ea-c (time now) 

    Project Cost Estimate vs. Cash Flow Analysis

    A follow up based on my previous post: analyzing graph of planned project cost against cash flow. 

    A simple comparison can be done using the WBS (Work Breakdown Structure) elements that contain all the tasks (the work to be done) of the project not yet realized. Each task has a cost assumption. Since WBS have a child / parent relationship, it's possible to roll up and summarize the cost information from the lower levels and upwards. The summarized total cost is the project cost estimate (or budget).

    As the project advances, it's possible to validate the project cost estimate against the cash flow (actual cost). A good estimate makes a better forecast of project cost at completion (close to the final actual cost).

    Project Cost Estimate and Cash Flow Analysis
    **The above graph illustrates three curves and is based on a hypothetical project with a number of tasks with an equal amount of work distributed equally over time,

    1. The green curve is the ideal case. In an ideal situation the beginning is usually slow because the project team normally acquires confidence with the project. Once the schedule has achieved 20-30% of the work, the slope of the graph will change and will accelerate due to the confidence and knowledge acquired. At 70-80% the schedule has reached a very good level of control and will continue with confidence to full completion of the project.
    2. The red curve is a representation of an early schedule spending too much money at an early stage. In this case, there is a risk to go over the budget, make mistakes, hence, not completing the project has planned.
    3. The blue curve is a representation of a late schedule. In this case, there is a  risk to work in a hurry toward the end, without the possibility of correcting possible mistakes.
    **Graph to be re-defined.

    In order to compare the project cost estimate with the cash flow at any given point in the timeline of the project, there is a need to know the actual cost of the work done. This data can be obtained from the organization 's accounting system or from the team that keeps track of the financial aspect of the project. 

    To analyze, and not only compare, in order to get more meaningful information of the project cost estimate against the cash flow at any given point, it's necessary to verify how much work has actually been completed to that point. This can be achieved with the Earned Value method. Please see my previous two posts for this topic:

    A simple interactive example of a progress report based on the Earned Value method (part 2)

    Another example of a responsive output graph linked to the previous post (input form) is the  cost and schedule performance index.
    • CPI (Cost Performance Index): greater than 1 means under budget; less than 1 means over budget.
    • SPI (Schedule Performance Index): greater than 1 means ahead schedule; less than 1 means behind schedule.
    In general, ideally, performance index greater than 1 means good and less than 1 means bad. But, each single case must be analyzed to get a better understanding of the situation at a given point in the project timeline, because greater than 1 might not necessarily mean good.

    In this example, there is no relationship between the predecessor and successor instance within the graph, hence, each case is to be treated as a singular case. But, in a real project network diagram where all relationships between tasks have been set to place, snapshots of various patterns can be created. This will give the opportunity to recognize, at a glance, each single case, i.e., the state of the project's situation at a given point (within that part of the project timeline that has been achieved).

    (Please read the "N.B." in the Input Data Form of the previous post "A simple interactive example of a progress report based on the Earned Value method (part 1)".


    (refresh rate every 10 seconds)

    A simple interactive example of a progress report based on the Earned Value method (part 1)

    Keeping track of project performance based on the Earned Value method

    The following is a simple interactive example of a progress graphic report based on the Earned Value method. This method uses an extra variable that represents the actual cost of the work done at a given point. This data is compared with the earned value to measure the performance of a project in terms of cost and schedule, with respect to the contract, baseline or initial agreement of the work to be done. So, it's possible, at any given point, to compare how much actual work has been completed against how much is expected to be completed. 

    For information on this topic see Earned Value Management and my previous posts A Simple Method for Keeping Track of Project Performance using the Earned Value Method and Multiple Projects Performance Analysis using the Earned Value Method.  More information can be found in any project management related material.

    The example consists of undertaking and completing 10 "equal" components in 10 working days with a budgeted cost of  $10,000.00, based on a fixed price contract. Hence, the project has the following initial agreements:
    • estimated time duration = 10 days
    • estimated budget = $ 10,000 
    • equal components means that all components take an equal amount of time and money to build
    To see how the project is performing, use the form below to input the elapsed time to date, number of components produced to date the actual cost (n.b., data is bounded by initial agreement ). So, it's possible, at any given point, to compare how much actual work has been completed against how much is expected to be completed. Moreover, the variance calculations shows the situation of the project, that is, if the project is running ahead or behind schedule and if it's under or over budget.


    Input Data



    Output Data Graph
    This is a simple output graph illustrating cost and schedule variance against time. This chart can be customized and enriched with more details to suit specific purposes and further analyze each single case at a given point of time.
    (CV = Cost Variance: a positive value means the project is running under budget, a negative value means over budget (spending more than what is planned for) and a zero means the situation is on track.
    SV = Schedule Variance: a positive value means the project is running ahead of schedule (producing more than what is expected), a negative value means behind schedule and a zero means the situation is on track.)



    (refresh rate every 10 seconds)



    Another example of a responsive output graph linked to the above Input Data form is the  cost and schedule performance index.
    • CPI (Cost Performance Index): greater than 1 means under budget; less than 1 means over budget.
    • SPI (Schedule Performance Index): greater than 1 means ahead schedule; less than 1 means behind schedule.
    In general, ideally, performance index greater than 1 means good and less than 1 means bad. But, each single case must be analyzed to get a better understanding of the situation at a given point in the project timeline, because greater than 1 might not necessarily mean good.

    In this example, there is no relationship between the predecessor and successor instance within the graph, hence, each case is to be treated as a singular case. But, in a real project network diagram where all relationships between tasks have been set to place, snapshots of various patterns can be created. This will give the opportunity to recognize, at a glance, each single case, i.e., the state of the project's situation at a given point (within that part of the project timeline that has been achieved).

    (Please read the "N.B." note inside the above Input Data form)


    (refresh rate every 10 seconds)


    Interactive example using PERT estimating technique

    Regardless of the technique you use for estimating tasks, each estimate has to be quantified into a number. There are different ways for estimating project tasks, for example: 
    • Use of Historical Data - "similar" projects categorized in a knowledge database system can be retrieved and consulted when making estimates.
    • Use of Experienced Resources - estimating is a team effort, and the contribution from experienced resources in making estimation is very valuable.
    • Use of Estimating Databases - make use of industry databases made available by organizations.
    In many cases estimates can be made more accurate by applying a simple PERT (Program Evaluation and Review Technique) model. PERT is an estimating technique that uses a weighted average of three numbers to come up with a final estimate.
    The PERT distribution comes out of the need to describe the uncertainty in tasks during the development of a complex project having thousands of tasks. Estimates were needed to be made intuitively, quick and consistent in approach. The PERT distribution is a probabilistic model based on Beta Distribution, and it derives its estimates based on the probability of occurrence. A version of this four-parameter Beta distribution is called a PERT distribution and makes the assumption that the MEAN = (MINIMUM + 4*MOST LIKELY + MAXIMUM) / 6. The default value of 4 scales the height of the distribution. This extra equation allows the four parameters to be determined from three input values: the minimum, most likely and maximum, which makes it ideal for modeling expert opinion of  the uncertainty of a variable.
    • E = Expected Value = (O+4M+P)/6 (this is the "weighted" average equation
    • P: Pessimistic value (this value is maximum, because it describes the case when things go wrong)
    • O: Optimistic value (this value is minimum, because it describes the case where things go right)
    • M: Most Likely value (this value describes the case given normal problems and opportunities)
    For example, let's suppose we want a more accurate estimate of a task duration that is collocated in a Project Network Diagram, given the following values:
    • P = 20 programmer days  (pessimistic value when everything goes wrong)
    • M = 15 programmer days (most likely) 
    • O = 10 programmer days (optimistic value where everything goes right)
    Use the following interactive form to get the expected task duration (mean value) for the above example.
    (Similar tasks can be categorized to create a histogram and it's possible to use the last chart below to highlight the mean value graphically, as stepped area across all other values).


    Input Data (M,O,P)





    Output Data Table (PERT Estimate)
    (refresh rate every 10 seconds)






    Output Data Graphically (PERT Estimate)
    (refresh rate every 10 seconds)