Category: Software Engineering

What is RUP or Rational Unified Process?


So when I went searching for a current definition on RUP, much of the writing on it was at least four years old.  Here is the definition I came up with gathering the most current sources I could.

RUP is made up of three components:

  • Key Principles for Business Driven Decisions
  • A Framework of re-usable method content and process building blocks
  • A underlying Method and Process Definition Language

I will expound on these below.

Key Principles

The following are the key principles behind RUP:

  • Adapt the Process
  • Balance Stakeholder Priorities
  • Collaborate across teams
  • Demo Value Iteratively
  • Elevate level of abstraction
  • Focus continuously on quality

Framework

The framework is made up of best practices that have been used effectively in software development over time (e.g. Use Cases) and “Method Plug-Ins”.  Based on these, organizations develop different flavors of RUP based on:

  • Organization Maturity
  • Project Complexity
  • Organization Culture
  • Regulatory Compliance & Policy Requirements
  • Type of Development (Embedded vs Web App)
  • Organization Size

Method & Process Definition Language

Finally, the actual specification of the process is done in what is called a Unified Method Architecture (UMA) Meta Model.  This included things like phases, disciplines, activities, milestones, etc.

Phases, Milestones, and Disciplines

Finally, an important part of RUP are the phases that you go through and the milestones that are hit as you go through each one.  The below graphic from Shuja and Kreb’s book shows this well:

getfile

Within each of these phases, all of the disciplines are being done, but some more than others depending on the phase.  A discipline is defined in RUP as a collection of related activities.  RUP has the following disciplines:

  • Business Modeling
  • Requirements
  • Configuration and Change Management
  • Analysis and Design
  • Implementation
  • Project Management
  • Test
  • Deployment
  • Environment

The mixture of phases and disciplines leads to the famous “hump chart”:

I will conclude by quickly describing the phases:

Inception Phase

The following activities are done in this phase:

  • Estimate Scope
  • Identify Critical Use Cases
  • Exhibit and Demo one candidate architecture
  • Estimate Cost and Schedule
  • Detailed Estimates for Elaboration Phase
  • Estimate Potential Risks
  • Prepare Support Environment

Elaboration Phase

The following activities are done in this phase:

  • Stabilize Architecture, Requirements, and Plans
  • Mitigate Risks to determine cost and schedule
  • Establish Baseline Architecture
  • Produce Evolutionary Prototype of Production Quality components
  • Optionally do throw-away prototype as needed
  • Establish Support Environment

Construction Phase = Build It!

Transition Phase

These are some of the activities that make up this phase:

  • Beta Testing or User Acceptance Testing
  • Train End Users and Maintainers
  • Fine-tune through bug-fixing and enhancements

I hope this short overview helped you to quickly get up to speed on RUP.  There is certainly much left uncovered here, so if you interested, consult the sources above.

Alan Turing’s 100th Birthday & Gay Rights


Today I honor and thank the eminent Alan Turing for the seminal contributions he made to computer science.  Without him, I may very well be not typing on this computer.  The tragic death of Alan Turing also brings up a prescient political issue of today, Gay Rights.  Homosexuals should not be made second-class citizens in any society, especially one like ours in the USA that is supposedly based on equality.

Say what you will about gay marriage, but if the government is to recognize marriage as a legal event, then it should be recognized for all citizens.  No one, especially people such as Turing who contributed so much to humanity, should be driven to suicide by a feeling that they are ostracized from their own society.

I have never posted anything political on this blog and rarely discuss my politics in professional life.  But the 100th birthday of the founder of my profession forces me to look at these two things and lament that he would still be treated as an outcast by some if he were alive today.

A Professional Engineering Exam is coming!


Finally!!  An exam from the people (NCEES) that do the Professional Engineer licensing exams across different states for software!  This is a HUGE step in the right direction for the professionalization of software engineering.  My home state, Virginia, is one of the states asking for the exam!  Soon, you can be a licensed software engineer, just like a civil engineer.

See more on this story here!

Top 10 Living Software Engineers in the World Today


This is my humble opinion.  Please leave feedback!  I know there are probably people out there I should have included.

(All ages are as of 2013)

  1. Steve McConnell – He wrote the bible, Code Complete.  Enough said. (Age:50)
  2. Linus Torvalds – He wrote and is the architect for one of the most used operating systems ever, Linux.  Oh, he did Git also. (Age: 43)
  3. Kent Beck – TDD, Agile Manifesto Signatory, jUnit, XP. (Age: 52)
  4. Barry Boehm – Software Economics, COCOMO, Spiral Development (Age: 78)
  5. David Parnas – Invented Information hiding and de-coupling. (Age: 72)
  6. Grady Booch – Helped invent UML and RUP.  Seminal person in Software Architecture. (Age: 58)
  7. Martin Fowler – Agile Manifesto Signatory, Refactoring, and wrote the classic Patterns of Enterprise ApplicationArchitecture. (Age: 50)
  8. Tim Berners-Lee – Invented the WWW for heaven’s sake. (Age: 57)
  9. Fred Brooks – Wrote THE classic, Mythical Man-Month and also a Turing award (Nobel Prize of Computing) winner. (Age: 81)

So, you’ll probably notice the list only has nine people (if you read this far).  I’ve included the best for last because he is also the most controversial.

Bill Gates (Age: 57)

Now many people may be upset with this choice and say that he was a businessman. True, he was a businessman. But he was also a Software Engineer. He was a programmer (1, 2) and then a project manager, if you will, for MS-DOS; one of the most used operating systems ever.  He was also the Chief Architect of Microsoft for a very long time when some of the most used programming languages (e.g. Visual Basic, C#) and products (e.g. Windows) were produced.



Sabermetrics for Coders


An very interesting book has been published recently by O’Reilly called Codermetrics.  While I don’t agree with everything the author writes, he should be applauded for his innovative new way at looking measuring developer productivity.  For too long, we’ve had Dilbert-like managers trying to measure programmers on things such as “Lines Added” or “Amount of Check-ins”.  These types of examples are insulting to professional developers and we usually try to find clever ways around it (tons of comments for instance).  Jonathan Alexander takes a different approach by using common sports stats like an “Assist” and applying them to software development.  I would get an “Assist” every time I helped a developer on my team fix some code or answer a tough question.   The other developer would have to approve that I did indeed “Assist” them.  With all the publicity of “Sabermetrics”, Billy Beane, and “Moneyball”, this book is right on time.  Check it out!

Glitches


So, I’ve been playing way too much Modern Warfare 3 (MW3) and I’ve noticed a new word that at first glance was a replacement for “bug”.  Players refer to “glitches” in the game where say a body will lie suspended in air even though they it fall to the ground.  It doesn’t stop the game, but it is not expected behavior.  Now I doubt that there was a requirement in the MW3 software development plan that stated, “All bodies, once shot, will fall to the ground.”  And they probably didn’t have a test case around it either.  But because it is a game based on reality, you notice when something deviates from reality.

In my graduate testing course, we had specific definitions for terms like faults, bugs, and errors.  But we never mentioned the word “glitch”.  The Software Engineering field needs to get ready for this term and to help that, I’ll attempt to define it.  Now the Oxford English Dictionary defines a glitch as a:

A surge of current or a spurious electrical signal (see quots.); also, in extended use, a sudden short-lived irregularity in behaviour.

Interestingly, it seems Astronauts used the term a lot.  Here is a quotation from John Glenn:

1962   J. Glenn in Into Orbit 86   Another term we adopted to describe some of our problems was ‘glitch’. Literally, a glitch is a spike or change in voltage in an electrical circuit which takes place when the circuit suddenly has a new load put on it.‥ A glitch‥is such a minute change in voltage that no fuse could protect against it.

I think these two pieces of information help define a software glitch.  One, it is short-lived and the application continues to run smoothly overall.  Second, it is very hard to reproduce and hence creating a test case for it is also inordinately difficult.  Third, because it is short-lived and doesn’t bring the system down, it is a possible siren of something more troubling going on, but it could just be a “one-time” thing.  Very similar to the movie “The Matrix” where Neo notices a “glitch in the Matrix” and it alarms the others because that usually means that the Matrix is being changed by the agents.  Although it could also just be deja vu (the glitch Neo saw).

A Historic Bug


The recent “bug” that afflicted the BATS trading system will probably be one for the ages and go along with other famous bugs like the Ariane 5 rocket and Y2K problem.  Of course BATS is calling it a “freak one-time event”, but this bug caused massive losses of money.  Fortunately there was no loss of life, but past bugs have caused this  like the Therac-25 radiation therapy bug.

I am a huge advocate for Software Engineering and the growth of this profession.  When I study the growth of similar professions, such as Civil Engineering, the government did not get involved and create certifications like the PE until there were massive loss of life due to bridges crumbling.  It is unfortunate that a similar type of software bug will cause the public to take notice of the pervasive influence of software in our society and needs to be recognized as a profession in its own right.  There have been close calls like the Toyota brakes problem which had a lot of software in it, but was ultimately the software was not found to be at fault.  Here’s to hoping that the government and public don’t wait to recognize Software Engineering as a profession.

New Software Engineering High School!!


Joel Spolsky just posted on a new high school being opened in NYC that will concentrate on creating software engineers!  What a great concept and it’s totally awesome that it will become reality!  If universities can’t change their CS curricula to keep up with the rapidly changing field of software development, then hopefully this high school will be the antidote!  A very exciting development!

Where does the acronym ALM (Application Lifecycle Management) come from?


I became interested today in where this ALM term comes from.  It is involved a lot with what Microsoft does on the Team Foundation Server (TFS) front and frankly, I’ve thought it to be just another marketing term for Software Engineering.  BUT, I wanted to investigate and dig deeper….

The best I can tell, the acronym ALM comes from PLM or Product Lifecycle Management.  The Wikipedia article on PLM has a good history of the term and how it came to be used at Chrysler in the mid 1980’s.  They basically started centralizing all designs, documentation, etc. of the Jeep Cherokee into one database to manage its creation.  Sounds a lot like ALM to me today.

It also makes sense that the term would come from manufacturing.  This article from 2002 talks about the transition in the manufacturing industry from Computer-Aided Design (CAD) tools to a more holistic approach of PLM.  There was also a boon of Computer Aided Software Engineering (CASE) tools in the 1980’s.  CAD leads to PLM.  CASE leads to ALM.  We both went from individual tools that did design, requirements, etc. and integrated them into one tool or system.  That seems to be the evolution.

The borrowing from manufacturing also makes sense as so much of Software Process comes from that industry. Kanban, Lean, CMMI, and on and on.  Deming, one of the greats in manufacturing process, is cited often in software process literature.

So there it is, ALM comes from PLM which all originated in the auto industry with the Jeep Cherokee.  Who would of thunk it? 🙂