vctechno

Let’s discuss what are your options if there are some constraints which are preventing you from using agile methodology or simply if your customer does not want to use Agile methodology. Well, why not use hybrid of Agile and Water fall approach. Tie your deliverables as required by your customers to water fall steps. Let’s look at the following steps Requirements Gathering Designing Coding Testing Go ahead and create requirements and design document and submit it to your customer for sign off. Take your coding and testing steps and see if you can use some of part of Agile methodology in these steps. Try doing following in 2-4 week iterations: Create stories from your requirements document Assign points to your stories Prioritize your stories Develop and unit test your stories Perform automated acceptance tests and deploy Deploying every 2 week gives your Business Analysts a chance to validate and verify your software. Any resulting issues can be fixed early and will be less expensive to fix. Deploying every 2-week gives your team a short goal which your team can try to achieve and once the team’s goal is achieved, the team will get a sense of achievement and hence this will boost team’s moral. The team will get confident each time an iteration is successful. Not only that, by deploying every 2 week you can measure the development velocity of your team and hence will have more insight in to when the whole software can be delivered. You can take necessary steps if you feel that by this development velocity delivery of the software will be delayed. Another thing which I want to highlight here is that Agile is less document oriented. No big requirements document, no big design documents, just enough documentation which you feel is necessary. For example, some times we create very detailed design documents explaining how the screens will look, which database tables will be used, what will be the pseudo code , what will be the sql query etc. Instead of going in so much detail why not a screen design and few words about its functionality. In fact I would prefer to draw the screens with my hand and update the screen when the developer has developed it. Believe me you would save a lot of time and probably be able to code your screen in the time you will be writing your detailed design document. Another reason not to write design documents in so much detail is that no one can be 100% sure about the sql, the database tables and code logic and no one can guarantee that these won’t change. We must welcome change and if we don’t we will fall in our own trap where in the end we will realize that we are running out of time and then these very detailed design documents are left untouched and now suddenly your code and the supportive documents are not in sync. Otherwise also if we know the things will change then why write it. Let coding take its own course, let the development happen with bare minimum documents and in the end produce your documents from your code / software and not the other way around. All of you who have looked in to RUP and if ever tried to produce those documents will probably realize the pain of doing so much documentation. Sometimes we forget our main goal. Our main goal is to produce working software and not lot of unnecessary documentation just to comply with a methodology. If just by writing few words can convey a software function then please do not write hundreds of lines just to convey the same function in detail. I have seen low level design documents with various sections inside those (For example, Screen Design, Description, Constraints , Database tables, Sql queries, interacting units.) Lets make it simple a screen design ( hand crafted) and just enough detail about its functionality. Another thing if your customer is not requiring you to submit these low level documents then why make these so much great. My suggestion lets make our life simple by making things simple, by reducing variables, by not over engineering anything , by being open minded and by welcoming the change. Let’s not make a methodology our religion (be it RUP or Agile or any other) and then keep believe in it for the rest of our life.

We are still debating in most projects whether to use Agile or use traditional approach. I find at least two reasons as to why its difficult in moving from traditional water fall / other approaches to Agile (1) our customers are unaware of how agile can help them build something they actually want. (2) Some of us have made traditional software development approach as our software development religion. We feel threatened by the fact that what ever we have learned in our schools and during our past experiences of developing software applications using traditional approach is suddenly not the right approach. In traditional approach the design won’t start till the requirements is finished. Coding won’t start till design is finished and the testing won’t start till you are done coding. The reason which was given was that you must gather all and correct requirements before you design because if a requirement is wrong then everything from design to test is essentially a waste. I guess in doing that we missed one major thing and that is human factor. First of all we should stop the over use of the word “Requirement”, and try to find out what are the preferences of our customers. Preferences change more frequently than requirements. (An ideal software solution would be one where there are no requirements but only preferences.) Let me ask you this, if you plan to build a custom home for your self, can you write each and every detail of your house in a piece of paper, give it to builder and then come back when the house is completely build. Do you think that whatever you were imagining while writing your so called requirements is exactly what you got? You might be getting something close to what you were thinking but not exactly what you want and sometimes it could be totally different then what you have thought. That’s where the difference lies; there is a difference between what you think you want and what you actually want. Now instead of building the whole house and then showing it to you, if the builder shows you every week or so what he has build so far and what he will be building in next week and each time asks you if you are satisfied? Now let’s say you are not satisfied with what ever was built last week or so and you want the builder to redo or change something. If the change is simple builder would probably do it for free. But lets say doing that change would cost some extra $ . Now you will have three choices (1) Not to do the change (2) Pay extra $ (3) Trade in some other feature of your house. (E.g. may be not to build the deck and instead do the change which is more important to you). The outcome would be totally different if the builder used this approach. At least there won’t be any surprises when the builder finally delivers you the house. Similarly if there are no surprises when the software is put to production then you have a satisfied customer and hence a successful project. Water fall or other approaches works fine if there is no change in the requirements. No change means you were able to document exactly whatever your customer was thinking (not saying) when you were documenting the requirement. Another issue is that sometimes we don’t know exactly what we want until we see it. Take the example of buying a car. How do you decide that you need a particular car? Well, simply put, you will actually look at a car and if you like it, you will go ahead verify other specifications and buy it. You requirement is that you need a car but which particular car buy is your preference. We all have seen that most of the time when software is delivered it does not meet our customer’s needs and preferences and then we start blaming our poor requirements gathering, wrong software design and may be bad technology selection. But I guess the blame goes to the fact that we were not ready to accept that fact that requirements could be poorly documented. Human beings to some extent are afraid of change, simply because changes are unpredictable and so we do not welcome changes easily. I guess time has come to solve this software problem and instead of resisting change why not welcome it. Traditional approach resists change but Agile welcomes change. Agile software development methodology eliminates element of surprise by releasing software in short iteration (2-4 weeks). In each iteration you plan, design, code, test and then release your software. Every 2 week your customers get a chance to look at your software. With each iteration, they will have more insight in to what they will be getting in the end. They are welcome to change their preferences and even after 2-week, if what ever you have developed, is a waste then let it be. It’s far better and more productive than keep working on developing software for a year and then realize that more than 50% of the software is waste. At least we all know that changes done in early stages of software development are less costly compared to changes done in later stages of software development. In the end I would say that I am not sure whether Agile will work for real-time and satellite/rocket software’s where whole system must be designed and tested before it can be put to use but I assure this approach works for rest of the application software.

In part-I, I wrote about how dialog boxes can make your application look infested with bugs. In order to solve this, as a designer your aim should be to minimize dialog boxes as much as you can and if a dialog box is really a need then think about making it a modeless dialog box. Let us assume you have a web application where you want to create a web page to display a list of items. Consider its design; you need a list page and an button to add items to this list. Now, as a designer, in order to provide the add functionality, you will either create another webpage or you will create a dialog box depending on the information you need to display and capture. If the input form has less number of fields (3-4 fields), then most probably you will choose a dialog box. Reason being, by using a dialog, you are letting the user to add the item and also letting the user to view the list of already added items at the same time. Now think what happens if there is a pop-up blocker and pop-ups are not allowed on your site? User clicks on the ADD button and your web page will probably blink and that’s it. Your well thought dialog will be eaten by the blocker. Now you can rely on the user to figure it out or expect to get a maintenance call. In the first scenario, you are relying on user’s consciousness and yeah, he should know what you were thinking while designing your application. My suggestion is let’s try to be innovative and let’s design for the user and not for the application. Now regarding the above dialog issue, we can add input fields, which we were displaying in the dialog, at the top of the list page and provide button and a button next to it (See fig. below). ---------------------------------------------------------------- Headers--> First Name Last Name Email Address ---------------------------------------------------------------- Inputs--> Field1 Field2 Field3 ---------------------------------------------------------------- List--> First Name1 Last Name1 Email Address1 First Name2 Last Name2 Email Address2 First Name3 Last Name3 Email Address3 First Name4 Last Name4 Email Address4 First Name5 Last Name5 Email Address5 For editing you can either provider edit image/button in each row or a EDIT HTML link. In the list above we achieved the same functionality as of a dialog box and much more. Much more? Well using this approach you can easily provide copy row functionality also. Consider the list below; a user can enter values in Field1, Field2 and Field3 for First Name, Last Name and Email Address and press to add a new row. User can also click on edit button/link next to each row, which will copy the row data on Field1, Field2 and Field3. Now user can edit the data and press to save changes or change something and press to create new row (copy functionality). Hope this helps. I will be back soon with more user interface design issues.

Okay, “blog” readers, lets discuss something about user interface design issues.There are so many of these but lets take one at a time and my random pick is dialog box.There are so many things the way we design our user interfaces, which we can improve on and we should improve on. I have seen some applications, which we use on a daily basis improving on it but some still do it the old way. Most annoying feature of some of these applications is the modal dialog box. So let’s find out what is bad about these dialog boxes.As we all know dialog boxes are classified as (1) Modal and (2) Modeless. Modal dialog box is that, which require a user to respond to it before doing any other action on the application which produced it. On the other hand a modeless dialog allows a user to perform other actions also, on the same application, while it is active.Dialog boxes are useful when we need to get some input from a user or if we need to give a response back to a user. Dialog boxes become more helpful when a user is viewing a list of items and he/she wants to add another item. Using dialog box in this case lets user add another item, while viewing the list.Now the real question, if a dialog box is so useful then what is wrong with it?Well, out of the two types, modal dialog box is really the most annoying.Consider “Font” dialog in MS Word. It is modal in nature and when it is active, it won’t allow you to do any other action on the word document you are working on. Consider its use now. This dialog box is used to change the “Font" properties of the selected text. So let’s say you select some text, open this dialog box to change font and then realize that you need to select some more text. The only option you have is to close this dialog and then select more text and then open it again. Now think if this dialog is modeless (just like “Find and Replace” dialog in MS Word), in that case you don’t need to close it to select more text. A small annoying issue is solved. (To our rescue, MS word has a font tool bar also to perform similar action, which most of us use.).Now can we live without these dialog boxes? I would say minimize dialog boxes in your applications, especially, if it’s a web application. All those pop-up blockers on user’s machine can make your web application look infested with bugs.There are some other alternative designs to dialog boxes also, and I will try to write something about that in my next blog, till then bye.

The purpose of testing can be to show that the software works or it can be to show that the software does not work or there can be another level where the purpose is not to prove anything but to produce higher quality software. When we say quality, a lot more gets added to the whole process. The testing simply does not become a procedure to find bugs but something where one set of tests try to fail it and another set tries to improve it( increase in usability/"easy to use" is one such improvement).Black box testing, white box testing, bottom up approach, top down approach etc. has always been there. To my understanding the goal is still the same , making sure (1) what we built is what was expected by the user and (2)Another level, where the software exceeded user's expectations and software is really solving his problem and not creating a new problems of its own kind. Today morning while driving I heard this analysis on radio about automakers. Their big challenge is that they design their cars based on user requirements or who would be driving the car etc. But the issue is , as they were saying, most of the time a user doesn’t know what he/she wants till they actually see it. This is what happens to us also when our system goes to production. We can always argue use agile/RUP/CMM etc. to avoid this but still we always find this issue.There is another issue and that is our test cases. Most of the test cases are written either to satisfy the requirement or to satisfy the design. This is not a bad thing (although I have read some articles which say the word “requirement” is bad. Another topic of discussion!).
I would divide testing in to two levels (1) Business Process Testing. (2) Code level testing.
Arvider has already posted his views on "Business Process Testing". But there is another level " Code level testing" where you go down to the code level, making sure you test each method in the code(Method coverage), Making sure each statement gets executed at least once (statement coverage), Branch coverage etc…. This is where GACC, RACC comes in to picture.Now you can always say that , that would be a lot. Well you do not need to achieve 100% of Test Coverage and also in order to do this you do not need to change what ever you are doing but you need to look at your Test Cases and produce smart test cases. How you produce smart Test Cases? I will try to write something about it soon.