Gnubbs Blog

Today I had an exam. It has been a long time since I had to take a final. I kinda forgot how much they suck.

I think that my exam went well. I went into it with something like a 95% in the class, and felt pretty comfortable with all of the questions. I botched 2 of them, but that happens sometimes.

Regaurdless, I am done. I learned a lot in the class and hopefully get at least a B. If not I have to pay for it out of my own pocket… Got done with my final at about 1pm, and discovered that it had snowed a foot while I was in the exam. Hasn’t stopped snowing since. Hopefully it will keep snowing and Stephanie and I will get tomorrow off work. Last I checked there was about 18 inches of snow outside.

Life is good — unless you are my buddy Schriver. He was supposed to fly out of denver tomorrow and it just isn’t going to happen. Sorry man.

1. Review the following this week
• IEEE 1233
• IEEE 830
• IEEE Spectrum Oct 1995
2. Requirements Elicitation
1. “Lack of user input” is most common cause of challenged projects
2. Req elicitation is the process of discovering reqs for system by communication with customers, system users, and others with stake in the project
3. Development team has to take the inititive — otherwise it will not happen
3. Challenges of Requirements Elicitation
1. “Yes, but” Syndrome
• Users reaction is human nature
• Need to get “yes but” out of the way early
• Anticipate and add time and resources to plan for feedback
• User interfaces are especially prone to this
• David Lamb (insert graphic)
2. “Undiscovered Ruins”
• The more we find, the more we realize there is to be discovered
• Where are we done with requirements elicitation?
• First scope the req elicitation effort by defining the problem or problems that are to be solved
• Empoy techniques that help find some of those ruins and get stakeholder buy in
3. “User and Developer” Syndrome
• Charecteristic — User doesn’t know or can’t articulate what they want
• Response — Recognize and appreciate user as a domain expert
• Charecteristic — Users think they know what they want, until they get it
• Response — Use techniques to mitigate: storyboarding, role playing, prototypes, etc.
• Charecteristic — Analysts think they understand users problems better than the user
• Response — Put analyst in users place
• Charecteristic — Everybody thinks everybody else is politically motivated
• Response — Get over it.
4. “Living with the sins of your predecessors”
• Like it or not, users and developers remember what happened in the past
• Team unilaterly cut important features out of the last release
• Need to build trust, slowly. Do not over commit!
• Build success by delivering highest priority features early in the process
4. Requirements Elicitation Techniques
1. Interviewing Techniques
• Simple, direct
• Context free questions — Prevents prejudicing users, but is harder than expected
• Exploring solutions to find undiscovered requirements
• Convergence on some common needs will initiate “requirements repository” for later
• At interview time
• Establish a profile of the user
• Assess problem
• Understand the users environment
• Recap your understanding
• Assess possible solution
2. Requirements Workshops
• Most powerfull technique
• Gathering all key stakeholders for a short, but intensely focused period
• Use of an outside facilitator experienced in requirements management
• Brainstorming is the most important part
• Preparing for the workshop
• Sell the workshop concept
• Ensure participation of the right stakeholders
• logistics
• Try and prevent Murphy’s Law
• Includes travel, snacks, etc.
• Warm up materials
• Project specific info
• Role of facilitator
• Introduce goals
• Manage meeting
• keep focused and under control
• Workshop agenda
• Running workshop
• Allow human behavior and have fun with it
3. Brainstorming and idea reduction
4. Storyboards
5. Use cases
6. Role playing
7. Prototyping
5. Requirements Elicitation Guidelines
• Assess feasibility
• Sensitive to organizational and political considerations
• Identify and consult system stakeholders
• Record requirements sources
• Business concerns should drive requirements
• Domain constraints
• Record requirements rationale
• Consider multiple viewpoints
• Prototype poorly understood areas
• Use cases
• Define operational requirements

1. Unified Process
1. Phases — very loosely defined, sometimes backtracking is appropriate
2. Iterations — Each iteration results in a small portion of functionality that is fully implemented, tested, integrated, etc.
3. Waterfall — Basically condense the entire project into a single UP iteration. It never really worked this way, and led to very high levels of project failure. Rework generally occurs long after original work, so is very expensive.
4. Iterative Development mitigates rework because you are only doing arch, design, test, etc. as needed. If things don’t work you can go back and fix while cost is still cheap.
5. (Question) In agile development, what about complex architectures? Generate in a very early iteration, then live with it. XP practioners change architecture frequently early in the project. This means they have a stable architecture earlier than a typical design/freeze architecture up front.
6. Waterfall model can be useful if you don’t have to learn anything. If working with systems where requirements, architecture, design are very well understood.
7. Patterns are the biggest contribution OOP has made to software engineering. Using patterns allows you to focus design/creativity/energy on what is unique to your app.
2. Software Project Management Best Practices
   
• Develop Iteratively
• Manage Requirements
• Use component architecture
• Model visually using UML
• Continuously verify quality
• Manage Change
1. Requirements Engineering – application of scientific principles and techniques for development, communcation, and managing
1. Communicating reqs changes has to be painless
2. 
3. Component Development Lifecycle
• 
• What does a component do?
• What are it’s interfaces? — If interfaces are well defined and stable, then other groups/developers can work on other components in parallel
1. How does iterative development work in this environment?
1. Generate enough system reqs for several iteratations
2. Each iteration, hand off system reqs for detailed design, coding, test, etc.
3. Integrate changes and test
2. What goes into requirements engineering?
• Elicitation, specification, management, analysis, verification
1. Requirements Elicitation
1. Identify relevant sources of requirements
• Customers/Users
• Government Regulations
• Marketing/Sales
• Business Strategy
• Limitations/Constraints
• Test/V&V group
• Competition
• Key Customers
• etc.
2. Determine what information is needed
3. Analyze the gathered info for implications, inconsistencies, unresolved issues
4. Confirm understanding with sources
5. Synthesis into usable format
2. Outcome of good elicitation activities (see lecture slide)
3. Outcome of poor elicitation activities
• Dissastified customers
• Constantly changing reqs
• Solving wrong problem
• Difficulty implmenting
4. Why is eliciting requirements hard?
• Colb learning style research, tied with the software lifecycle phases
• 
• Iterative development helps this because cycling through the different learning styles has been shown to lead to a deeper understanding.
5. Obtain requirements from all possible sources
• observation and measurement of the current system
• interviews with the customer
• current system documentation
• feasability studies
• competitive analysis
6. Quality Attributes
• Performance
• Scalability
• Usability — “good usability invites experimentation”
• Extensibility
• Maintainability
• Safety
• Portability
• Security
• Stability

Before my first day of classes, I was honestly somewhat nervous.  It had been a very long time since I was in school, this would be my first class in a new CS department, and this is also my first graduate class.

It was amazing how comfortable it felt being back in a classroom.  I guess I have been going to school far longer than I have been doing anything else, but I was still surprised.

On the flip side, it felt very strange doing homework again.  It was also strange to be looking at a calendar that someone else had made that dictated my schedule for the next 3.5 months.  I also have to get back in the habit of writing things down by hand.  That is a skill I have pretty much dropped since graduating.  Reading will be another challenge.  I will read more in the next couple of months than I have in the past couple of years.  That will take some adjustment.

I have to say that, so far, I am impressed by the instructor.  Comparing this course to the software engineering course I took my senior year of undergrad, this instructor is way more modern and experienced.  My undergrad course basically taught the old school water fall model of software development.  My current course discusses that, but mostly to point out why it doesnt work.  Instead we are studying iterative development cycles, and talk a fair amount of taking this to it’s logical extreme — XP.  This is a welcome divergence from what I expected before starting the class.

Also, going to a very large (28,000 students), public unversity is much different than the medium sized private university I got my undergrad at.  To pick something entirely superficial, I have to say the student bodies at CU are much more finely developed…  I think I saw more mini-skirts walking to my first day of classes than I did cumulatively over 4.5 years at Case Western.  It is not a bad thing now that I am older, married, and nominally more mature.  Had the girls looked like this at case, I fear I would have learned much, much less.

Since I am now a student, I need to get out of here and go drink some beers.

1. Requirements engineering is a key problem for software development process
2. “We know why projects fail, we know how to prevent thier failure — so why do they still fail” — Martin Cobb, Cobb’s Paradox
3. Standish Report (can be viewed online)
1. Challenged Projects — Delivered, but late or with reduced functionality 52.7%
2. Impaired — Never Delivered 31.1%
3. Successful — Delivered basically ontime with full functionality
4. Success Factors — In order of impact — User Involvement, Executive Management Support, Clear statement of Requirements, realistic expectactions, smaller project milestones (iterative development)
5. Requirements Volatility should be meaused and reported even if management does not specifically ask for it.
6. In a timeline from the Tape Disk market, there was a large milestone marked “Miracle Happens Here”. This was taken very seriously in the project group. In this case, in order for the project to be succesful there had to be a technological break through. The project could proceed up to this point, but until R&D made thier breakthrough it would then stall. Example from Prof. Dameron, not report.
7. Impaired Projects — in order of impact — incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations
4. What dos a software development process do for you?
1. You get the info you need
2. When you need it
3. in a form that you can use
1. Effective mangement environment allows itterations to work correctly, without interuption, breaks, lost resources, etc.
2. UML diagramming vs. Making up your own diagramming is like drawing an electrical diagram and making up your own symbols.

Since all of the presentations and lectures are available online, my notes are probably going to be pretty sparse. However, if I put them online I will have access to them even if I don’t have my notebook handy.

For next lecture:

1. Read Standish Report exerpt
2. Read Unfinished Voyages (sorry for the crappy link, but I can’t find it on the Standish site)

Starting today my life is going to be much more busy.

At 2:00pm I start the first class I have taken in 4 years.  “ECEN 5543 Software Engineering of Standalone Programs“  It is the first class in a 3 course graduate level series in Software Engineering at the University of Colorado Boulder.  At the end of these three courses, I will either get a certificate or apply for the Masters of Computer Science program at CU.

That is still a year away, but today is the first step.  It should be interesting.  My undergraduate coursework was more or less entirely coding.  These courses are much more focused on design, specification, testing, etc.  For me, this should be a good thing.  My projects at work are notoriously short on specifications and design documentation.  As far as I can tell I am the only one who is bothered by this, but it is still something that I would like to resolve.

There are some things that remain to be seen.  Looking at the sylabus, it looks to be based more on old school waterfall style software project management.  That is fine and a widely used model, but I hope there is also discussion of XP and Test Driven Development.  I have started using some of the principles from XP, and have seen a significant increase in my productivity over the past couple of months.

Here is the syllabus from the course a couple of years ago.  To access the current one you have to be a CU student, but this should be representative.  I hope to blog prodigously about these classes.  My plan is to put both the highlights of the lectures, and the entirety of my notes and homework solutions online.  I am pretty lazy though, so you might have to make do with my totally sporadic blogging as usual…