Jim Schardt’s Blog

Does your software/web application gain the benefits of Object Orientation (OO)? Well designed object-oriented applications exhibit high cohesion and low coupling. Small changes to requirements mean small changes to the code. Just because you use an OO language like Java,C#, C++ etc. does not mean your application benefits from object-orientation.
Continue reading…

Readers of this blog may have noticed a new feature in the column on the right side of the page. An icon that will take you to DevelopMentor’s blog aggregation site. There you can find other blogs related to software development. Below the icon are links to Concepts, Tools, and Type topic areas that readers of this blog should find interesting. Check it out.

As a contractor to DevelopMentor I teach, mentor, and develop course content on the topics I cover in this blog. If you need to further your education in software development (and who doesn’t in this fast paced world) consider what DevelopMentor has to offer.

In my last post I talked about how requirements are really the stuff that goes in and out of your system, the black box. The “stuff” are things like data, documents, objects, requests, events, and when “this stuff happens. But what else constitutes requirements (stuff)?
Continue reading…

Thinking of your system / software / business unit as a black box is a great way of avoiding statements that are not requirements. Consider the statement, “R-1.1 The Payroll Department shall send the Summary Employee Report to the Accounts Auditor each Friday by 1600 GMT.” This requirement is for the “Payroll Department” system. The black box represents the entire Department. As a requirement for the Department the R-1.1 statement describes something (the Summary Employee Report) that goes from the inside of the black box to the outside, namely to the Accounts Auditor. We can experience and measure the report leaving Payroll no later than 1600 GMT on its way to the Accounts Auditor.
Continue reading…

What is the hardest thing to estimate on a remodeling construction job? I asked a friend of mine who happens to be a contractor in the building trades. Not surprisingly he said it was estimating the hidden elements of the job. (Hmmm… software is mostly hidden)
Continue reading…

Many years ago an instructor of mine pointed out that software is invisible. Unfortunately his name is lost to me in the mists of time. As he did with me, I challenge you to show me this thing we call software. Can you see it?
Continue reading…

The last time your team used Use Cases, the Business Analyst (BA) became defensive. The final set of Use Case were inconsistent and missed a lot of requirements.

What’s the solution? In my experience it can be summed up in one phrase, “Write down what you know, when you know it.”
Continue reading…

Have you ever noticed that the more effort a person puts into their work the more likely they are to defend it, even when the work has obvious flaws? Filling out Use Case templates from top to bottom can lead to just that situation.
Continue reading…