Advertisements

Software is everywhere – especially in cars


Amazing article in NY Times talks about how software is taking over everything, even our cars!  We can’t see this software and it’s been exposed to hacking (Jeep being driven off the road by remote hacker) and manipulations of emissions tests at Volkswagen.  People in the article argue cogently that this code should be made open-source so that we can examine it and know what we are buying as consumers.  At the very least, it should go through some of the strict reviews and audits that airplane software goes through.  Congress and the federal government should act before something bigger happens than the two examples above forces them to.

Advertisements

Software Engineering is all about Modelling


There is a great article over at O’reilly entitled “Striking parallels between mathematics and software engineering”.  I’ve never really  thought about the parallels of Math and Software Engineering.  I’ve thought about Civil Engineering, Medicine, and the Law; but not Mathematics.  To summarize, the author says that Mathematics is really about modelling and that is what we do in software engineering continually, especially when following object-oriented paradigms.  It is striking and has opened my eyes to a whole other avenue to explore when it comes to Software Engineering.  Just thought I’d share 🙂

Latest ACM Turing Award Winner Announced!


Lesile Lamport, a Principal Researcher at Microsoft Research, has been announced by the Association for Computing Machinists (ACM) as the winner of the 2013 Turing Award winner.  The Turing Award is the equivalent of the Nobel Prize in computing.  I always look at these prize winners as “Gods” of the computing world and I think it’s important that we remember and honor our history if we are to progress as a profession.  He won it for his his work in distributed computing, which I can tell you from my graduate course, is some very difficult stuff.  He also created LaTeX among other things.  Congratulations!

Official News Release

What is Software Engineering in the 21st Century?


In February of 2001, 17 people met in Colorado to discuss how to move the Software Engineering discipline forward.  They were frustrated that their more lightweight, adaptive methods were not being tried while watching heavier methodologies continue to fail with over budget and over schedule projects.  They correctly surmised that a revolution would be needed to make the Software Engineering community hear and, more importantly, implement their solutions.

They could have left in disagreement and disarray over non-essential questions like: What’s better, Scrum or Feature Driven Development?  Fortunately for the Software Engineering field, they didn’t.  They wrote a Manifesto which is shown below:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Their Manifesto worked beyond their wildest dreams!  Like any revolution, there was resistance, especially in the establishment.  But after 10 years, it was clear that they had won the war.  The establishment could not resist any more and all discussions on Software Engineering now have to include Agile practices.

After the American Revolution, the American founding fathers were faced with a whole new set of problems that were in many respects bigger and more complex than winning the revolution in the first place.  The Agile Revolution finds itself today in a similar situation.  Questions such as, “What is the best way to scale Agile to an entire Enterprise?” are what need to be answered today.  The Agile movement would be wise to not throw away everything that came before it in Software Engineering, but rather mix and modify it to set our discipline on a new course.  This is what the Americans did when they took the King concept, mixed it with democracy, and came up with the modern presidency.  I’m looking forward to the next 10 years to see where this mixture leads us!

So, What is Requirements Work?


Interesting article from the Spring Issue of IEEE Software entitled, “So, What is Requirements Work?”.  The author, an obvious expert in the field, goes on to conclude that Requirements Work is basically helping people help themselves.  I like this definition.  As a Requirements Analyst, you cannot know every single domain you will be parachuted into as your career progresses.  No one can be an expert in Medicine, Law, Accounting, Botany, etc.  Instead, “smart” Requirements Analysts depend on the domain experts that already exist to guide them to the problems that need to be solved.  Then, they are able to get out of domain experts/stakeholders the specifications of those problems.  Finally, the requirements analyst can specify those requirements in formats that are decipherable by multiple stakeholders (developers, customers, etc.).

I’m not sure I agree that Requirements Work involves coming up with solutions though.  It seems to violate some central core of Requirements that were taught to me, “Concentrate on the problem, not the solution.”  But, I’ll admit as a former software developer, I can’t help to think of solutions when I hear problems.  I have to be judicious, though, about when I bring them up.

Check the article out yourself when you get the chance!

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.

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.