In 1970, Dr. Winston Royce a Computer Scientist from Austin, Texas, published a paper titled “Managing the Development of Large Software Systems.” Dr. Royce criticized the software development methodology of the time, the Waterfall method, which utilizes a sequential approach to software development. He asserted that software should not to be developed like an “automobile on an assembly line,” where every phase of the project must be completed thoroughly before the next phase can begin, where the process must be well thought-of and planned beforehand. This used to be traditional method – the waterfall method. But this had some serious setbacks. Firstly, conflicts arose sometimes between adjacent departments due to their inability to communicate effectively amongst the various departments. Royce argued that this lack of communication might hinder the robustness and functionality of the product being assembled. Secondly, the methodology of the traditional method means the architect[s] must outline every requirement and specification before the product can go through any of the phases – such as the coding phase, the design phase, the testing phase. And lastly, teams have only one chance – in most cases – to get things right. There is no going back to a phase if the product is found to deviate from its intended functionality.

These pitfalls gave rise to a new methodology, the Agile methodology. In agile, every aspect of the project and every phase of the project is revisited multiple times throughout its lifecycle. And each phase has many repetitions, professionally called iterations, and each of these iterations lasts for only about a couple weeks. This gives developers more opportunities to revisit something that was missed or something that was not well-thought-of/planned.

Instead of committing to market a piece of software that is guaranteed to be released at a specified data regardless of its robustness or functionality, agile empowers teams to continuously re-plan their release to increase its value in the marketplace when and where it is released.

This is how software ought to be developed, but, unlike what organizations may claim, they aren’t doing anything close to Agile’s actual definition. Because the human-being is a fickle-minded creature, often deviating from its given job due to irresolution and instability.

As such, the traditional method works fine for starters.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Decision tables are one of the more powerful functional testing methods, partly due to their logical decision-making structure. Here is how they work:

• Conditions are identified as inputs; actions are identified as outputs.
• In certain cases, the conditions are equivalence classes.
• For every possible combination of inputs, the output is identified and marked.

The size of a decision table is greatly impacted by the choice of conditions. Thus, the conditions have to be identified wisely.

Pretty straight-forward thus far. Decision tables involving equivalence classes have a characteristic appearance.

But people often make mistakes when the conditions refer to equivalence classes. Particularly when the equivalence classes are mutually exclusive, and are disjoint sets. As such, it is not possible to have a rule where two entries are true. For a particular rule if one equivalence class is marked true, it doesn’t matter what the other classes are marked – don’t care entries. Thus, the number of rule count increases.

This creates a problem.

Let’s say we have a decision table as shown below, where c1, c2, c3 refer to conditions and a1, a2, a3 refer to the actions. And we have Rule 1-4 identical to that of rule 9. Let’s say we have two versions of this table. Although version 1 is redundant, it does not have a problem. In the second table there is a problem. Because, in addition to being redundant, the two redundant rules (1-4) and 9 are not identical – their action portion differs.

   Frist Version.                                                   Second Version

This problem of redundancy and inconsistency creates tremendous strain on the part of a developer. In cases such as that of version two, two observations can be made:

1. Rules 1-4 are inconsistent with that of rule 9.
2. The decision table is nondeterministic.

Here is the bottom line: Care Should Be Taken When Do-Not-Care-Entries Are Used in A Decision Table.

This is the drawback of decision-table based testing, because of the dependencies in input domain. On the other hand, the benefits of decision-based testing are that indiscriminate selection of input values from equivalence classes as done in other testing methods such as boundary-value testing (this is done when the variables are assumed to be independent) are not made here. In a decision table, impossible rules are emphasized with the use of don’t-care-entries and the use of impossible-actions.

In summation, decision-table based testing should be used for applications that indicate these characteristics:

1. Prominent if-then-else logic.
2. Logical relationship among input variables.
3. Calculations involving subsets of the input variables.
4. Cause-and-effect relationships between inputs and outputs.

Works Cited

Jorgensen, Paul C. “Decision Table Based Testing.” Software Testing: A Craftsmen’s Approach, 4^Th Edition. New York: Auerbach Publications, 2013. Safari Books Online. Web. 7 Mar. 2016.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Hello visitor,

This is my first post! I am a computer science junkie and I’ll be posting the fascinating things I learn related to my field.

I love hearing your opinions and thoughts on my posts. So please leave a comment below!

Buvaneshwaran T

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Chapter 4 of The Clean Coder starts to explain some practices when it comes to coding.  Many do’s and don’t’s, some myths busted, and general good practices are told.  It tries to explain that coding is hard and that it shouldn’t be done when one is tired.  Not only that but it shouldn’t be done when you can’t focus at all.  Not being able to focus on your coding is a route to disaster and prone for mistakes.  It even claims that when you are in “the Zone”, a time where you are coding quickly and nothing is stopping you, it’s a mistake waiting to happen.  Although coding quickly can yield some results, it’s never perfect.  I’ve experienced this myself even.  When coding quickly to try and make a due date for assignments, there are usually always errors whereas work that is done over time and at reasonable times, it’s almost always better.  The book then goes on to explain about how music and other distractions can also causes errors as well.  Although music might help some, the book claims is puts coders into “the Zone” which is where you don’t want to be.  You want to be in complete and total control over your coding, not someone else in your head.

Chapter 5 on the other hand talks about something I’ve been told many many times before, and it’s still something I have yet to fully experience or see the point to, and that’s Test Driven Development.  I understand the concepts behind it and how it can help, but I just don’t understand why you want to write the tests before you have actual code to test.  I want to start with a plan of what I want to write first, figure out what I want to code, and then attempt to start it and THEN test it.  Once I have something worthy of testing, I test it.  Why would I want to write a test on something that I haven’t even created yet? When creating the program for the test I created, I might even change how it works, which means I have to change how the test works anyways!   It just seems silly to me, but to each their own I suppose.

The only thing that I agree with with TDD is that you want to write your tests alongside your code.  You wrote something that needs a test? Write a test for it now.  That makes perfect and reasonable sense to me.  Don’t save writing all the tests for last.  By writing your tests as you go, and even testing them, you can see any problems on what small problems you are currently working on, and can fix it now before it can lead to greater errors later on.

Anyway, in regards to what was actually in the book, it just lists some practices on how to conduct TDD.  It explains the three laws and how the three laws can lead someone to better structured code rather than a mess of code.  However, one needs to practice at it because following the three laws won’t yield perfect results.

From the blog CS@Worcester – Nick Richard by Nick Richard and used with permission of the author. All other rights reserved by the author.

The next couple of chapters in Clean Coder deal with communication in terms of saying yes and no.  Obviously in a work environment, one is prone to say yes to their boss all the time; but that is not what a professional does.  A professional needs to learn how to communicate effectively with their boss and peers and explain how long something will take.  Saying that you’ll try is not good enough, your boss might expect a 100% working product and you might only give a 50% working product, resulting in disappointment and anger.

However this doesn’t mean that you should say no to everything, you have to do something while at work, it’s your job! And this is what chapter 3 goes more in depth about, saying yes.  When you say yes you need to be definitive about what you are saying yes you.  Say yes to something that you know for a fact that you’ll get done, something that you know will be 100% working by the date you defined.  There should be no lack of commitment when saying yes.  Saying yes as a professional means that you are taking full responsibility of the task and making sure that it is functioning to the standards that it needs to be at, and possible even higher.

Overall, when it comes to taking on tasks in a work environment, you shouldn’t take on every single task that is asked of you, you will be overbooked, and I agree with this.  If I kept saying yes I would more likely than not know what is the most important task that needs to get done.  But not only that, I probably would’t get some of the tasks done at the right time.  However I do need to do work.  When choosing tasks to do, I should be confident in what I’m working on and know roughly when it will be done.  I could let my team members know how long it would take to get something done and when I would have a complete product working.  As in the previous chapters, being professional is about taking responsibility in your work.

From the blog CS@Worcester – Nick Richard by Nick Richard and used with permission of the author. All other rights reserved by the author.

One of the first projects that I’ve been working on this semester is the OpenMRS Project.  “OpenMRS is a collaborative open source project to develop software to support the delivery of health care in developing countries.”  I found this to be an interesting project to work on since it’s an open source project with many talented developers as well as supporting a good cause.  However, the setup to begin developing was definitely challenging.

Since OpenMRS is open source, all of their code is published on GitHub, so being able to jump in to developing should be easy. Wrong (for me at least).  First I was introduced to a new IDE, which is no big deal, that’s easy enough.  The IDE I was starting to learn was called IntelliJ IDEA, or as I like to call it, IntelliJelli.  What’s nice about IntelliJelli is that you can directly import a project from GitHub.  However, I did not do this at first.  I thought it would be easier to pull the code from GitHub and just import it myself.  Upon doing this, as planned it imported all the code, but it was missing everything; and what I mean by everything is that it wasn’t created as a maven project, it was missing some maven imports, it even had errors that I don’t know how to explain.  After being very confused and disgruntled with all the unknown errors I had, I decided I would try importing directly from GitHub.  Why I didn’t think of that in the first place is beyond me.  It worked flawlessly.  It created it as a maven project by default, it had all the imports it needed, everything was perfect except for a couple of lines that had a few errors (later I would find out that these errors are not important).

In order to finish getting a working build of this code, I had to open the console and use a few commands to get things working.  First I needed to work my way towards the OpenMRS directory and do a clean maven install.  This built the project as a maven project (again I believe? If not officially for the first time so it’s recognized).  Once the maven clean install and updates were finished, I was ready to start the server that’s contained within.

OpenMRS works within a browser so I had to work my way to the webapp folder and start the jetti program.  Now starting the jetti server worked, however I had nothing to actually work with, I needed some form of UI and database to work with while developing.  Thankfully, OpenMRS supplies an option upon the initial setup to create a fake database of people with certain information and characteristics.  To store this database, I also needed MySQL.

So the first step to this was downloading and installing MySQL, which also needed Python, visual basics, SQL connector, etc.  So before I could even get the database setup, I needed other programs and languages as well.  After installing those and finishing the installation of MySQL, I was ready to begin the installation of the Legacy UI supported by OpenMRS.  Thankfully there was a very helpful tutorial provided by OpenMRS on their wiki page, so I followed those instructions and placed the generated UI file into my appdata folder.  With this I was finally ready to begin the initial setup of OpenMRS in my browser.

Upon starting MySQL and the OpenMRS jetti server, I opened up my browser and went to localhost port number 8080.  I went through the custom / advanced setup so that I could select creating a database of fake people to use and to communicate with MySQL.  It took awhile for it to create the data, but it finally worked and redirected me to the log in page. Success.  I logged in and went straight to the database to see what I could find for data.  I found 2 people.  I can tell that the identification numbers for the people are not in chronological order, but I feel like I should have more than 2 people in my database.  I’m hoping to resolve this issue soon.

In the coming days / weeks I’ll be working on a new project with OpenMRS that deals with radiology.  The radiology team seems excited to be helping us students succeed, which is very thoughtful of them and I’m grateful for that.  Working on the tickets they suggested we look into will be interesting and I’m hoping it will put my knowledge to the test.

Until next time… Nick

From the blog CS@Worcester – Nick Richard by Nick Richard and used with permission of the author. All other rights reserved by the author.

Hello everyone,

I’m Nick Richard I’m a senior in my last semester here at Worcester State University.  I majored in computer science with a minor in mathematics, and I’m very excited, yet nervous, to finally be graduating from school.  Soon I’ll be thrown into the real world and have to make a living like everyone else.  I have no doubts that I’ll struggle though, I think I’ll do just fine.

But enough about the formal talk, I’ll talk about some of my interests and wrap things up.  When I’m not at school, or working diligently during classes, of course, I work at the local Webster Kmart. Yes, Kmart’s still exist, who would have thought.  You can tell the place is dated when you walk inside however.  Other than that I am an occasional video game player (PC, sorry console players), feel free to discuss games with me.  I also like being outdoors in the summer with camping, snowboarding in the winter, and I’m looking to start going off-roading in my 2005 Ford Escape XLT.

Well, that’s enough about me, I’m looking forward to posting on this blog and sharing my ideas with all who are interested.

Nick

From the blog CS@Worcester – Nick Richard by Nick Richard and used with permission of the author. All other rights reserved by the author.

Here is an extremely useful tutorial to get Ubuntu running on a Google Chromebook (netbook).

The link to the resource can be found here.

-Michael Malloy

From the blog Michael Malloy - Worcester State Computer Science » CS@Worcester by mmalloy1 and used with permission of the author. All other rights reserved by the author.