Software Requirements Evolution


Software Requirements are evolving to keep up with users’ demanding appetite for applications. Simple “The system shall” statements have grown into User Stories and Storyboards. It used to be that talking about the GUI was verboten when gathering requirements. We software practitioners knew how to use the magic of creating software and the lowly users just needed to tell us what they needed and we would pull the software solution out of our proverbial hat. Not so anymore. Practically everyone has a smart phone or smart device (even my 3 year old) and the word “app” is universal thanks to the iPhone. Can I really gather requirements from my 3 year old for her new drawing app using Use Cases? Obviously no. Granted,the use cases may be used by the software developers but my 3 year old can’t even read for Christ’s sake.

Most users now know if they want a mobile app, web app, or desktop app. They know the differences and strengths of using these from years of experience. That’s why I think a more agile way of gathering requirements where quick prototypes and storyboards are used to gather feedback are meeting users’ requirements much better. If it’s a web app, well you have obviously constrained the application down to what HTML, JavaScript, CSS, etc. can do. So why not make a quick prototype of that? If they want an iPhone app, well there’s a pretty set style of doing that set by Apple. Obviously, we software professionals still have a part to play by asking, “Are you sure you won’t want to eventually have an app on the Android too?”. This leads to conversations about different architectures, technologies, and the cost/benefit analyses of each. But older ways of doing Software Requirements are becoming decreasingly beneficial with the changing “tech savvy” of users.

Please don’t get me wrong, there are still places to use Use Cases for certain kinds of projects. They are a tool in any good Software Requirements professional’s toolbox. But newer tools are coming out that need to be considered much more to keep up with software professionals’ ever changing user base.

About these ads

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.

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 BeckTDD, 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 FowlerAgile 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 (12) 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.



New Application Lifecycle Management (ALM) Group in Washington, DC Area!


Are you interested in Software Engineering?  How to use ALM tools to make your software development organization?  Then come join us on Thursday, June 21 for the inaugrual meeting of the DC ALM Group!  Hope to see you there!

Kick-Off and Continuous Deployment with Team Foundation Server

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!

Great article on distinction between Software Engineering and Software Development


Even though this article is five years old, it is just as salient and relevant today as then.  The author’s main argument is that software development is applied software engineering.  What a great way to think about the two concepts!!!  I think he’s exactly spot on, but it’s hard to get to this idea because of our experience of engineering is applied physics and physics is applied math.  I’ve never thought about applied engineering!  I always thought it should be applied computer science, but I was never comfortable with that idea.  I rarely use concepts from CS.  Maybe algorithms, but that’s about it.  This really fits!!  I encourage you to read this article if you’re interested in how our field is shaping up in this century!

http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html

 

Follow

Get every new post delivered to your Inbox.