What Users Say Translated to Software Engineering!

I need a report that shows me how much I spent yesterday!

Not an atypical ‘requirement’ from a business users’ point of view, huh?  What do you as a Software Engineer DO with this and similar statements?

Let’s start with a couple of questions that we can use to expand and clarify on a statement like this:

  • You SHOULD already know what business unit this user is in but if you are at all unsure, ASK!
  • You SHOULD already know what data this user’s business responsibility has access to but if are you unsure, ASK!
  • Are there other data fields that are important to the report being requested that are NOT within the reach of this Business User?
  • Are their calculations that are to be performed for this report and are the data required for these calculations currently available within the ‘reach’ of this report?

As a recap, the Business Unit and its accessible data will point you to a segment of the organization’s Entity Relationship Diagram (ERD).  This can act as an initial data context for these discussions.  If other data is needed for this report but is not within the organization’s data context, then you will need to inspect the rest of the Organization’s ERD to confirm that there is a usable path to get to this related data or you may have to create one.

Once this path is confirmed as available, defined as a needed new path to existing data, or clearly identified as a new data point that has not yet been collected, we can add this to the Proposed Solution ERD.

The process of collecting the data together for the delivery of this report can then begin with the answers to a few other questions:

  • What business condition(s) should trigger the creation of this report?
    o   Frequency: Daily, Weekly, Monthly, Quarterly, Annual, etc.
    o   Number of transactions (since last report, or overall in increments, etc.)
    o   Data relationships indicating an situation: normal, abnormal, other
  • What conditions will affect when certain calculations are Needed or Not Available?
  • Where can new data be found and how should it be stored for use in this report?
  • What sequence or search criteria should be used to select data to be included in this report?
  • What changes should be made to the data to indicate that this report has been delivered for a certain date range, business condition, or other situation?

The process model can now be built as a Data Flow Diagram or Object Model with Methods to show the identification of the situation(s) that will trigger this report; the sequence of data collection and selection, the calculations that are to be included, and the production of the report.

The distribution of this report is still not determined but with just a few more questions, a Software Engineer should be able to determine the media, distribution path, and list of recipients.

Software Engineering: How do you start?

There are interesting challenges in applying the art and science of Engineering Disciplines to Software Analysis and Design.

If we accept the notion that we need as complete a collection of Requirements as possible either for a full blown application solution (change or new) or a SPRINT to add functionality to either an existing application or to get a new one started, then we also need to decide which models we are going to use to collect these requirements from the Business Users and Sponsors and record them so that the Development and Testing efforts can be coordinated.

The model choices we have are several:

  • Object Models
  • Data Models
  • Process Models
  • Swim Lane Diagrams
  • Use Cases
  • State Transition Diagrams
  • Event Diagrams
  • Data Mapping Diagrams
  • Nassi / Schneiderman Diagrams (don’t remember these?)
  • or simple Flowcharts (a real throwback to a long time ago!)

Which ONE is a good start?  Which combination will the Business Users and the Development and Testing teams understand with sufficient similarity that we can believe we are all talking about the same solution and not something that is not clearly communicated?

One suggestion I would propose is that the “Engineer’s” in the project team do NOT pre-select a model to start with.  Instead, prepare a list of fairly open ended questions for the Business Users and Sponsors and LISTEN to what they have to say about how THEY envision their solution.

You may find that they are very comfortable talking about the information that is available and supportive of their hoped-for solution AND they might also talk about the business events that occur when the data is first available and other events that will change the nature or state of that data as it is used in performing the business.  OR, your users may be more comfortable describing their solution in terms of the Objects or Topics of Interest and the behaviors that they demonstrate as the solution delivers its capabilities.

Once you get the sense of how your users like to describe their vision of the solution, you can pick two or three of the appropriate models to show that you “Get” what they have been saying AND you can also introduce them to the models that seem to represent their vision as close as possible to the ‘syntax’ that they are comfortable with.

The translation of their narratives to you about “Requirements” and the feedback from these diagrams should (underline and bold “should”) facilitate the communication between the Technical and Business contributors assigned to your project.

Let’s CLOUD the Issue..

I just read an article about the word “CLOUD” being more of a verb than a noun so I thought I would add my two cents to this discussion and Cloud the issue some more.

This article was written by someone in a networking group that I have attended in the past and I will, hopefully, get to talk to the author again before too many people get my opinion about whether CLOUD is a verb or a noun.

However, to be clear: I disagree that this word “CLOUD” is more verb than noun and here’s why:

  • If CLOUD is a verb then what observable action takes place when someone ‘clouds something’?
  • If CLOUD is a place where data is stored by owners so that it can be retrieved later to multiple devices then it’s a place and that makes CLOUD a noun.
  • If moving to the CLOUD is a complicated process for an organization regardless of the size of that organization, then the process of moving data to a CLOUD is a verb but the location where that data resides is a place (again) and therefore is a Noun (again).

The other discussions in the article are very valuable and clearly prepared to advise other IT professionals on how to approach the issue of Cloud usage for an organization.  He provides a list of ‘fundamental truths of corporate cloud strategy’ that are worth applying to anyone who is involved in moving an organization into CLOUD usage with very solid reasons to make this change.

However, the premise of this article that CLOUD is a verb is the one point that I cannot agree with.

Because of this opinion I feel obliged to provide a link to this article and so that you can review the author’s credentials and make up your own mind about this; however, considering how far we have yet to go in creating a mature understanding of this CLOUD capability, I think this debate will continue for a long time to come.

The link, then, is:

http://bit.ly/vJBvNk

Thanx for reading!

Structure Programming – Advice from IT.Toolbox

The only point I disagree with in this article is about replicating code for readability!

DO NOT REPLICATE code ’cause it also replicates Maintenance Costs!

Other than that – Bravo to the author: Craig Borysovitch!

http://it.toolbox.com/blogs/enterprise-solutions/systems-development-structured-programming-guidelines-48980

 
bgbg

The First 90 Days

When I have been asked what I would do in the first 90 days of a new project as the Project Manager, my responses have typically included some or all of the following as a “Self-Orientation Start Up Plan”:

1) Gather the latest project documentation available from the following sources:
a) Portfolio Management files for priority, expected Return On Investment,         relative co-dependence on other proposed and active projects
b) Program Management files for direct dependence on other planned or active projects to determine just how much dependence there is on deliverables and work products from other projects
c) Process Management files for guidelines and standards for how projects are expected to be run for this client / customer
d) Project Management Files to determine if there have ever been similar projects run within this organization and for similar purposes
i) Collect available information on the Project’s / Program’s Scope, Objectives, Goals, Known Requirements and Risks from all perspectives
ii) Collect currently active Project Plans, Issues, Risks, Change Logs and Action Items for active related projects
iii) Collect current and recent Status information on all related projects that are under Execution during or before these first 90 days

2) Review the interrelationships between all available documentation AND
Identify the GAPS in this list where they are not available, not practiced by the client organization, or simply overlooked for this particular effort where others have complied more fully to the incumbent expectations
a) Prepare a list of what is missing, incomplete, or inconsistent in the existing documentation
b) Identify an initial set of Risks, Issues, and needed Action Items that should be acted upon before the final approval for this requested project is given to the Project Team
c) And Determine the recommended work required to complete these items OR get agreement that they will not be needed for this particular project (from the Sponsors, Funding Source, and the Steering Committee, at least)

3) Present and discuss what I consider the current ‘status’ and expected outcomes of the proposed project / program with the entire team of Business Sponsors, Targeted User Management, Steering Committee, Funding Sources, potential Team Participants, possible Third Party Vendors (and their current contracts) as a preliminary Kick Off Meeting

4) Come to an agreement on refreshed materials that satisfy the following Subject Titles:
a) Project Charter
b) Project Scope and Objectives
c) Project Requirements (High Level)
d) Project Budget and Schedule
e) Project Quality Review Schedule
f) Project Dependence on:
i) Third Party Vendors
ii) Other Projects and Programs
iii) Continued agreement on Priority and Delivered Value
g) Project Assigned Resources
h) Project Advisory Personnel
i) Project Steering Committee Members

At times, this information can be gathered in less than 90 days and THAT is a very positive sign of the health and potential success of the project that is being request. The longer it takes to find, understand and correlate these materials, the less likely this project is understood and therefore there will need more Risk Identification and Mitigation efforts to identify things we can learn about that might interfere with the desired successful results.

Orthogonal Views…

A current definition provides us this:

or·thog·o·nal   [awr-thog-uh-nl]
adjective

1.  Mathematics .
a. Also, orthographic. pertaining to or involving right angles or perpendiculars: an                 orthogonal projection.
b. (of a system of real functions) defined so that the integral of the product of any                   two different functions is zero.
c. (of a system of complex functions) defined so that the integral of the product of a               function times the complex conjugate of any other function equals zero.
d. (of two vectors) having an inner product equal to zero.
e. (of a linear transformation) defined so that the length of a vector under the                           transformation equals the length of the original vector.
f. (of a square matrix) defined so that its product with its transpose results in the                    identity matrix.
2. Crystallography . referable to a rectangular set of axes.

 

For Software Engineering, I like to apply this term to describe how two or more  conceptual models in different perspectives will net to Zero when components of an envisioned solution are checked off or aligned with one another.

WHAT does THAT mean?

There are four essential models that can be used to describe a business solution before it is actually specified, tested, or built:

  1. Process
  2. Data
  3. Event
  4. State Transition

When conducting the project phase of Analysis where Business Requirements are intended to be fully fleshed out, these models are used to capture the ideas and expectations that the users, sponsors, management, and technical contributors disclose to the analysts.

By reviewing and comparing each of these models to the others, we can create a list that has each component in each model aligned and “Checked Off” with components in the other models.  For example: A Process and an Event item should be found to describe the same business event from their modeling perspectives.  An Event should be aligned with the appropriate data components to determine that the event can, in fact, begin with a certain condition of the data and end with another.  The evolution in a row of data in a Data Entity should align with a State Transition that reflects and depends on this data transformation.

When each of these models is used appropriately and checked off against the others, every one of modeling components should be referred to and ‘checked off’ (none remaining unchecked)!

Hence, the “Orthogonal” and mathematical proof that a set of conceptual modeling drawings and their associated supportive documentation should net to “Zero” and prove that there is only ONE (and the same) solution being described by each of these models.

Ever Present Project Management Risks

Every project has Risks associated with the delivery of the Business Solution. These need to be discovered as part of the Project Submission process and continue to be anticipated and discovered during the ultimate execution and delivery of the requested business solution.

However, I also believe there are Project Management Risks that are inherent in the process of managing projects from the time they are proposed in a Portfolio or Strategic Planning phase through and including the delivery of the business solution that will be driven by the Project Management efforts.

My favorite list of these Project Management-specific Risks are:

1. Forward progress on an existing plan is at risk unless the team stays focused on the project’s scope and objectives and continues to work on the planned activities

2. Acceptance of Project Deliverables may be delayed by the Project Sponsors if they don’t understand the value, meaning, and importance of its content

3. Available Funding for the project may be recalled when other projects appear to be at a higher priority in the short term

4. Resources working on the project may be re-assigned to other projects if these other projects are deemed to have a higher need because of their timing, poor planning and / or management

Mitigation of these risks can be started as part of the Project Identification / Submission and Portfolio Management activities of each project before each is authorized for funding, resources, and a schedule; however, since these are ‘ever present’ risks, the measurement and risk assessment of these potential hazards must also continue throughout the execution of each project.

A very important early step in Risk Mitigation is Notification to all known participants and stakeholders that we will be identifying these items as Open Risks for the duration of the project. This communication is critical to set the expectations for the Sponsors, Users, Management, Technical and other specialized members of the project team, that we will be treating these items seriously throughout our project’s execution. These ‘ever present’ Risks should be added to the Business related Risks that can also be identified before Execution begins.

In parallel with this Notification of these and other more project-specific Risks, the team should be made aware of the tools and techniques that will be used to measure the impact of these Risks to the overall outcome of our project.

These tools can begin with several of the following approaches and activities:

1. Status Reports written in such a way that each detailed item in the report tells the audience what is expected to happen NEXT (see Risk #1 and #2) once each of the Status Items is included in the report:

a. EG. – The Communication Plan is complete and has been Accepted by the Project Participants and Approved by the Steering Committee.

i. This statement, although correct, leaves the reader thinking that there is nothing else to do now that the Communication Plan is finished. This is, clearly NOT what we want to leave them with.

b. Alternatively – Now that the Communication Plan is complete and Approved, the Project Management Team will begin calling the planned review meetings to measure the effectiveness of the Communication Plan objectives. During these meetings, the Sponsors, Steering Committee, and Participants will have a chance to suggest improvements or changes to the Plan based on our then-current experience.

i. This statement continues to report that the Comm Plan has been Created and Accepted, but it also outlines what must now be done throughout the project since this plan is ready for use / execution.

2. In order to successfully deliver scheduled Project Deliverables (see Risk #3), a Quality Assurance schedule must be established to review these deliverables as they are being developed to assure several things are true:

a. The Deliverable remains “In Scope” and aligned with the Project’s Charter and Goals

b. The Deliverable has not left out or added a new item as compared to earlier deliverables (Project Charter, Scope, Communication Plans, Technical Designs, etc.)

c. The Accepting and Approving audiences for each deliverable are aware of its content, intent, and value before each of these deliverables is ready to be presented to them as “Complete”

3. Regular reporting of the anticipated outcome of the entire project should be provided to the Sponsors, Steering Committee, and Participants so that they are constantly reminded of what they will be getting when the project is successfully completed. This will keep the anticipated value of the project’s results at ‘top of mind’ so that when other projects appear to be in jeopardy (See Risk #4), the decision makers will have the most current information about why our project should remain intact and on plan even if others are not able to maintain their momentum to their projected values.

a. Project scheduling tools and cost tracking capabilities will help to show how much progress has been made on each project against the plan along with predictions of the latest “Estimate To Complete” costs and time so that each project can be compared on, at least, this ROI or CBA level to support any decisions that might be considered for re-prioritizing or re-aligning resources from one project to others.

I assume that many of you have other ‘ever present’ risks attributable to the process and performance of Project Management itself and I would like to hear about them from you.  Please either provide a comment to this blog or send me an email with your thoughts at ‘whendoyoustoplooking@gmail.com’.

Thanx, bgbg

Remember Codd and Date?

These were two technology authors who were quoted on the subject of Relational Integrity and a Normalized Data Model.  Their ideas of reducing redundancy in the physical data schema and protecting the mandatory relationships between entities took a whole lot of attention about how to create, define, and manage data so that it was safe and intact for application usage.

They had rules and a syntax for defining data and a normalization process for creating a Data Definition Language (DDL) and Data Manipulation Language (DML) for all data necessary to support the functions of applications.

Use this link for a more detailed discussion on Normalization: http://en.wikipedia.org/wiki/Database_normalization#Free_the_database_of_modification_anomalies

Then, Object Orientation came along and added Methods, Self Contained Data, Anthropomorphism and some other terminology that, although valuable and additive to the definition of solutions, took our eyes off the ball of data modeling principles that are STILL fundamental to a reliable and cohesive solution to business and organizational needs.

Why have we let this happen?

The first computer bug – TODAY’s the day

Check this out about the first actual computer bug ever recorded:

http://www.computerhistory.org/tdih/September/9/

bgbg

Input – Process – Output

What exactly should a computer program do?  How will you know if the program you have written or requested to be written for you does what you need it to do?

It’s really a whole lot simpler than you might think.

If you, as a business user, can define what information is available to accomplish the automated task at hand (the purpose of the program).  And, you can define, in detail, the processes that are to be done using this available information (the calculations, manipulations, sorting, totaling, etc.).  And define the output results that this program should be expected to provide to you as the user, then you have defined the entirety of your requested program.

A program should only ever take INPUT, PROCESS it according to a business user’s specifications, and create OUTPUT requested by that user.  If a program tries to do anything else other than Process Input to create defined Output, then it is doing more than and probably unexpected things that no one asked the programmer to create.  This would be a BAD outcome.

The Software Engineering science of defining these specifications in these terms has been referred to as a IPO Diagram with three columns.  Can you guess what these columns might be?

IPO Table Sample v1 bg 20110812

IPO Table Sample v1 bg 20110812

If you try this at an appropriate level of detail, you should be able to get a clear understanding of how this can work for you in your business need; HOWEVER, remember that the amount of details you put into this effort will be reflected in the completeness and accuracy of the results.