Lean Principles Applied to Design

November 26th, 2007

I was impressed with the Lean Software Development process, and thought it would be worthwhile to discuss it in context with this Software Design knowledge area. The biggest takeaway I have is that of the principle of eliminating waste. (All the principles of lean should be implemented, but I like to identify a few words to associate with new ideas) For those who need some background, please visit Mary and Tom Poppendieck’s site.

As applied to manufacturing, eliminating waste seems intuitive. As in manufacturing, there are many areas (obvious and non-obvious) in software development where waste can be eliminated. And lean fits well with the strategies and methods of agile development. It is our duty as a CSDP to understand and apply these principles to our projects.

From the Poppendieck site, “Lean organizations concentrate on the rapid flow of value, because they have discovered the fundamental principle of Lean Six Sigma: quality, speed, and low cost are tightly linked; in fact, they work together to provide world class performance”. Just like the agile concept of customer focus, lean considers waste to be anything that does not provide timely customer value. This does NOT mean that you throw necessary methods or processes out the window. It means you must justify that the method or procedure provides value either to the customer or value to the process of creating value for the customer. For example, does that document need to be formally produced or would a wiki entry be good enough?

Finally, I think there is one thing that I keep hearing over and over at conferences and in books that is stated in the “LEAN Software Development” book by Mary and Tom Poppendieck, “..transferring practices from one environment to another is often a mistake. Instead, one must understand the fundamental principles behind practices and transform those principles into new practices for a new environment.” This is where we as a CSDP can help!

Allen

Software Design

November 12th, 2007

According to the IEEE definition [IEEE610.12-90], design is both “the process of defining the architecture,
components, interfaces, and other characteristics of a system or component” and “the result of [that] process.”

The SWEBOK identifies six sub-areas;

  1. Software Design Fundamentals
  2. Key Issues in Software Design
  3. Software Structure and Architecture
  4. Software Design Quality Analysis and Evaluation
  5. Software Design Notations
  6. Software Design Strategies and Methods

I subscribe to the IEEE Software magazine. One of my must read articles is “on architecture” by Grady Booch. I have been reading his books and articles since my college days. In the November/December 2007 issue he compares building architecture with software architecture. And in one page, he clearly states where the two disciplines differ and converge. Of course, books have been written on these ideas, but I now have a simple list anytime someones needs to have a discussion.

I have read and heard a lot of people talk about “software design“. I’m sure you have seen many compare it to building a building, or liken it to a craft, or even describe it as an artistic endeavor. At the last conference I went to, Alan Shalloway of NetObjectives, compared current software development to the crafts of the middle ages, before the industrial revolution! Even Grady Booch in the previously mention article observes that “the software industry has a long way to go to achieve the building industry’s level of predictability, reliability, and quality. ”

There are many ideas out there on design, I have mentioned lean development, design patterns, agile, and there are more. As a CSDP holder, I think we must consider the pro and cons of the different approaches and use the most appropriate one for our current project. Like the old saying (no animal cruelty intended) “there’s more than one way to skin a cat”. We need to have a variety of approaches in our toolbox, and like any proper craftsperson, know which tool works best for the desired result.

Allen

A Technique for Requirements

October 31st, 2007

I did mention that I have a high regard for Tom Gilb. He has a technique that I think is valuable, and as with all techniques, can be adapted to fit anyones environment. I created a presentation – Evolutionary Requirements Engineering. Here are is a definition of a requirement:

A requirement is a stakeholder need that a developer is planning to satisfy.
A stakeholder is any person, group or object, which has some direct or indirect interest in a system.

I created this presentation from resources provided by Tom at a conference I attended. I think the concept of stakeholder is known by everyone, but do you know who are the critical stakeholders for your project? Accordingly, you must consider the entire life-cycle and identify the different categories of stakeholders.

Another concept is that you must analyze the requirements you gather. It is important to distinguish the ends (requirements) from the means. – ‘Means’ are the design ideas we choose: the architecture, technology, strategies and other synonyms (They are whatever is needed to achieve the requirements). Identify the key requirements that have the greatest impact on your most critical stakeholder values and system costs. And these key requirements could be decomposed into more elementary ones.

Now that you have identified your critical stakeholders and key requirements, how do you know you have met the goal of the requirement? Here again Tom gives us a technique to apply to our development: quantification. Here is Tom’s Simplified Quantification Procedure.

P1: Make sure you are dealing with an ‘elementary’ variable.

P2: Describe the ambition level.

P3: Generate a corresponding Scale of measure.

P4: Specify Conditions

P5: Specify a Meter.

P6: Try out the Scale.

P7: Repeat process until you are satisfied

P8: Generalize the Scale with more Parameters.
For more details check out the resources at Tom’s website on “Evo”, Evolutionary Project Management & Product Development.

Allen

Software Requirements

October 24th, 2007

The second knowledge area is one of the first tasks in a project. Yet many people, those of the waterfall persuasion, may think that requirements work is finished when the coding starts. I’m sure that like testing, many managers think it is expendable when the project becomes time or funding constrained. However, a Professional should know that requirements need to be maintained/updated and tested against during the whole project life cycle. As with everything there are different classes and types of requirements.

Searching for a definition of Software Requirements, I start with “Software Requirements Engineering, Second Edition, Edited by Richard H. Thayer and Merlin Dorfman, published by the IEEE Computer Society Press in 2000 “. In the Introduction to Tutorial, the following definitions are found;

Software Requirements Engineering is the science and discipline concerned with establishing and documenting software requirements. It consists of: Software Requirements Elicitation, Analysis, Specification, Verification, and Management. Further, System Requirements Engineering is the science and discipline concerned with analyzing and documenting system requirements. A System can be considered a collection of hardware, software, data, people, facilities, and procedures organized to accomplish some common objectives. In software engineering, a system is a set of software programs that provide the cohesiveness and control of data that enables the system to solve the problem.

So those are the tasks involved, but what is the definition of a requirement? In the What is A Requirement? paper in “Software Requirements Engineering, Second Edition”, we find this: If it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement – period. That paper continues on to explain the qualifiers – characteristics and relationships – attached to requirements.

The collection of papers in this book helps the software engineer with the processes involved around requirements. Again, I strongly refer everyone to Tom Gilbs book: Competitive Engineering, as well as his other resources at his web site. He states a number of fundamental concepts for systems engineering that are applicable to our discussion;

Clear communication amongst the different stakeholder groups is essential.

In any system, there are several Critical Success Factors. They include both performance requirements (such as serviceability, reliability, portability and usability) and limited resource requirements (such as people, time and money).

The primary systems engineering task is to design and deliver the best technical and organizational solutions, in order to satisfy the stakeholders’ requirements, at a competitive cost.

His Planguage2 (the specification language and methods described in his book) supports all of his concepts with practical ideas and methods. His book has a number of practical strategies for good projects to adopt, and I recommend everyone should obtain a copy.

Next time we will continue our discussion with requirements.

Allen

UPDATE:

The SWEBOK identifies seven sub-areas;

  1. Software Requirements Fundamentals
  2. Requirements Process
  3. Requirements Elicitation
  4. Requirements Analysis
  5. Requirements Specification
  6. Requirements Validation
  7. Practical Considerations

Improving Your Professionalism

September 24th, 2007

How does an individual improve their professionalism?

I believe that first you must want to improve and be willing to support that desire. That can mean being disciplined to provide a time and place devoted to self-improvement. For instance, one hour devoted to reading a book or a journal like the IEEE Computer or IEEE Software. Or three hours on a weekend discovering or experimenting with a new (to you) software development technique. Or providing your software-engineering talents on a open-source project.

At one conference, I attended a presentation by Watts Humphrey on his Personal Software Process. I bought the book and started to do the exercises and tests. The goal of this process was to provide you with metrics on your coding capabilities, like how many errors/faults per lines of code you introduce, or how many lines of code per hour you write, etc. If you know how many errors/faults you might introduce, wouldn’t you want to try to find at least that many in your personal QA testing? If you know your average production of code, wouldn’t that help you in your estimation tasks? I intend to revisit that process again with my new development techniques!

We all write something like a requirement at different stages in a project. How many of us believe we can write a clear and unambiguous statement? A good start could be the use of the technique and process developed by Tom Gilb (see Competitive Engineering:A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage ISBN 0750665076 Publisher: Elsevier Butterworth-Heinemann by Tom Gilb.) He has a wonderful collection of resources at his website.

One other important point for improving your professionalism – do you conscientiously consider the ethical impact of your work?

Allen

Professionalism and Engineering Economics

September 5th, 2007

Let’s take a look at this section of the CSDP. This section is more about the person as opposed to the practice of software engineering. How does a professional conduct oneself? Firstly, I would start with the Software Engineering Code of Ethics and Professional Practice.

With a code of ethics as a base, let’s look at some ideas of what is a professional.

From IEEE Software, May/June 2007,Robert C. Martin of Object Mentor, Professionalism and Test-Driven Development: “A professional software developer ships clean, flexible code that works-on time. Unfortunately, many software developers use high-stress heroics to ship late, buggy, messy, and bloated code. ”

There are many examples of unsuccessful projects with blame attributed on a number of different reasons for the failure. Popular press and industry pundits like to call it the software crisis. According to “Software Engineering Volume 1: The Development Process, 2nd Edition” from IEEE Computer Society Press, edited by R.H. Thayer and M. Dorfman, in Chapter 2, “the term software crisis originated with the military”. As non-military systems became equivalent in scope, this term was applied to all software systems that did not deliver the goods.

From 24th International Conference on Software Engineering (ICSE ’02) Software Engineering Economics: Background, Current Practices, and Future Directions: “The field of software economics seeks to develop technical theories, guidelines, and practices of software development based on sound, established, and emerging models of value and value-creation–adapted to the domain of software development as necessary. The premise of the field is that software development is an ongoing investment activity–in which developers and managers continually make investment decisions requiting the expenditure of valuable resources, such as time, talent, and money. The overriding aim of this activity is to maximize the value added subject to an equitable distribution among the participating stakeholders.”

Developers should have professional responsibility for their work, and an awareness of the importance of appropriate ethical behavior in the group. They must also have an awareness of the impact of information technology on society as a whole and on individuals, and be prepared to handle a variety of issues arising in the workplace.

So that is some introduction to this knowledge area, and I will expand on it in the future. I leave with one question in mind – How does an individual improve their standing as a professional?

Allen

Design Patterns

August 28th, 2007

I have heard and tried to use Design Patterns ever since (and maybe before) the Gang of Four book. I have read and used Peter Coads pattern book, as well as using his Together product before it was bought by Borland. One of my more useful books was “Applying UML and Patterns” by Graig Larman. I continue to read and try to implement patterns in my work. However, I still haven’t got the hang of it. Just using good object-oriented techniques and using existing published code as templates doesn’t seem like a long term solution.

At the last conference, I attended a tutorial by Alan Shalloway of NetObjectives and bought his book; “Design Patterns Explained”. I have high hopes that this book will be that key that unlocks the design patterns concept. Having just read the preface, Alan had a become a very good object-oriented designer, and had learned about design patterns. The promise of his book, is that he will teach you how to apply patterns and learn why they work and how they work together.

I think I had a similar experience learning object-oriented coding – you struggle to understand why while you implement the techniques until at some point in time you cross over the chasm and realize what all the theory is about. There are two ways this happens, trial and failure, and/or instruction. This time maybe I can use this book to avoid some of those trials!

BTW, if you ever have a chance to attend a tutorial or read a book/article by Alan Shalloway, I highly recommend taking the time.

Allen

Book: Tom Gilb: Competitive Engineering

August 17th, 2007

Competitive Engineering:A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage
ISBN 0750665076 Publisher: Elsevier Butterworth-Heinemann by Tom Gilb.

I bought this book after taking Tom Gilb’s Tutorials at a conference in 2006. The conference was quite good, and I (along with others) was able to spend some time with a wonderful person. He is that unique person, which has a profound effect on your life. The book could be classified as a reference work, but it also presents concepts by building on previously introduced ideas. So I suppose it is a textbook that then becomes a reference book. The book introduces Tom’s “Planguage”, which clearly and unambiguously communicates management objectives and systems engineering requirements. To quote further from the book cover; Competitive Engineering encompasses Requirements Specifications, Design Engineering, Evolutionary Project Management, Project Metrics, Risk Management, Priority Management, Specification Quality Control, and Change Control.

I think that sums it up quite well, but I will give you some of my thoughts. Each page of the book can be a template for managing the entire Software Engineering life cycle. It defines concepts of the Planguage using Planguage. It gives guidance on how to use the different concepts, as well as how to combine the concepts into larger concepts. Planguage was designed to be specific yet flexible, just like the Software Engineering discipline. Just like Design Patterns, CE gives you a tool, that you can modify and custom fit to your environment, yet with a little explanation anyone can read, understand and use. I am still reading and learning from the book.

Tom has a number of interesting ideas and techniques, which anyone would do well to investigate. After all, there is no magic incantation or secret sauce that can produce good software, only tools and techniques t hat when properly used and applied, can help us deliver what the customer really needs and wants. I highly recommend this book as one of those resources.

Allen

Management of SE

August 9th, 2007

How does one manage Software Engineering?

In this case, I am defining “manage” as more than just a manager and controlling projects. How does one (individual, team, or manager) decide what is a good process to follow, or which SE principle applies? First I think that experience is the number one factor. Experience can compare the principle, process, or technique to similar instances and can suggest the probability of the outcome. I think this is also why most projects fail – somewhere in the chain of people and events, someone either ignored the past or could not do the comparison(maybe they had no experience). I know I have been involved with this issue on too many projects!

How does one gain this experience? You either pay the price to hire an individual with it, or you pay the price to develop it. Given a foundation of some level of experience, I think the next level (I will keep this vague in this discussion) can be obtained through study; reading, discussions, conferences, or courses. And of course I believe, based upon my own experiences, that experience develops better in a group rather than as an individual. In fact this may very well be why I believe in attending conferences.

For those that haven’t checked out the requirements of the IEEE CSDP, the application requires documention of at least a minimum of 9,000 hours of software engineering experience within at least six (6) of the eleven (11) knowledge areas.

I. Professionalism and Engineering Economics
II. Software Requirements
III. Software Design
IV. Software Construction
V. Software Testing
VI. Software Maintenance
VII. Software Engineering Management
VIII. Software Configuration Management
IX. Software Engineering Process
X. Software Engineering Tools and Methods
XI. Software Quality

The number of hours on the Report of Experience and Education Form must total at least 9,000 hours and software engineering assignment dates must indicate that the candidate has at least two (2) years of software engineering experience within the four-year (4) period prior to the application.

Allen

Paired Development

July 30th, 2007

Paired Programming is always brought up and usually discussed in any discussion of agile development. I worked on a project where we did pair programming. I considered it successful, but my recent attendance at the Better Software Conference sparked the following idea.

Paired Development with a programmer and a tester(QA). Logistics aside for the moment, a programmer writes the code sitting with a tester writing the tests for that code. They would decide on the design of the task (dependent upon the project constraints and procedures), and I would imagine they would review each others work. I believe review is the important concept in paired programming. I would think a trained tester would be more capable of writing unit tests then the programmer, since I find that the processes are complimentary and difficult to switch between.

This concept would need more thought, however if good processes are used and roles are defined properly, I think this might have some promise.

Allen