techVELOCITY Day

My company[southtech limited] decided to do a techVELOCITY day on every month. I think this is a nice attempt. The target is to arrange a seminar where people can present any technology that may have enough potentiality to use and get benefited.




I thought why not speak about agile method and try to make understand everybody some of the excellent features of agile development.I don't know whether i am success or not in that matter but I had good response and people were asking questions about how we can adopt that and in what sort of projects.




My main target was to describe the benefits of visual modeling and just enough documentation. Documentation is a good thing but people have to compare the benefits of documentation with the cost of its maintenance and effectiveness.
I also mentioned a comparison between agile and waterfall.I think adopting the complete lifecycle of agile development has few problems at this moment specially in the environment where I work. Some of them are Team empowerment,Customer involvement because if we fail to prove our customer the benefit of close involvement they will not give their timer so closely.
Any way, the techVELOCITY day was excellent and we enjoyed a lot.

Let's do it agile

“study of 6,700 projects, it was found that four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with late integration.”

Source: http://www.versionone.com/Resources/AgileBenefits.asp

The main problem of traditional development method is once one stage of the traditional/waterfall method has been completed, going back is impossible. If you go back it is costly and inefficient.

But on the other hand if you follow agile method, change is welcome. At the end of each stage/iteration you will have a working software. And the size of the iteration is 2/4 weeks.

The most interesting thing is agile says customer is a part of development. So where customer is a part of development, you can't have so many requirements gap and after all customer is getting a working software in every 2/4 weeks. so if there is any gap it is not going to cost you that much.

Agile says document but do not get lost in piles of paper.Agile includes some excellent practices and those are

-Active customer participation
-Respond to change
-Time boxing
-Iterative and Incremental delivery
-Use case driven
-Prioritizing requirements
-Team work
-Team must be empowered to take decision
-Pair programming
-Just enough documentation
-Testing is integrated throughout the life cycle
-JAD session/daily meeting/Communication
-Refactoring
-Feature driven
-Visual modeling- A picture is worth a thousand words

In traditional development for a mid size project the requirement specification takes few months and the boss loses patience and bullies all concerns to sign off the specification. Then the developers go away with the confident that they have the signed off requirements so no one gonna blame them for any problem. They design for few months and coding starts after several months.

When the customer gets the software, already it has been almost a year. When they start using it, they find their business changed a lot.
But in the case of time boxed delivery it would never been happened.

"another study of over 400 waterfall projects reported that only 10% of the developed code was actually deployed, and of that, only 20% was actually used."

Source: http://www.versionone.com/Resources/AgileBenefits.asp

Finally I am totally agree with cockburn and like to say "Waterfall is an acceptable way of failing"

Model your system more efficiently by SysML

Though I have not worked with SysML yet but I think it will give an excellent dimension of work to the Business/System Analysts as it covers a bit more than UML 2.0.
1. SysML stands for System Modeling Language and it is a “customization” of UML 2.0 for system engineering.
2. SysML is a generic language to model Systems and Products, it is not a process.
3. Because of their separate development, process and language are loosely connected.
4. UML and SysML are the same language different dialects.
5. SysML is specified as a UML2.0 profile.

There is few completely new diagram types in SysML and one of them is Requirements diagram. The benefits of Requirements diagram are;
1. You can show relationship between requirements and hence you can have a complete sense about which sub requirements are forming a main requirement.How the requirements are communication each other to form a complete system.
2. From the requirement diagram your prioritizing job will be easy and perfect.
3. Customer/user will be able to see their system more clearly.
4. You can use dependencies with stereotypes.

Finally i would like to say that a diagram says more clearly that thousands of word can not. So don't write pages after pages, use diagrams. You would be benefited and so your customers.
The diagram above shows how different SysML is from UML.

Who is doing What

For OO systems analysis and design method it is very important to define who (roles) is doing what(activities performed and artifacts produced), when (time order of activities) and how (guideline). I am experienced of working in an environment where you have to do all the things and eventually you can not do anything properly!!So work should be separated. My opinion and observation is if you separate your analysis and design task in the following way, you would get your job done properly.

UML and the concept

•Unified: The result of unifying three leading approaches to system modeling in the 1990s
•Modeling: Concerned with the simplified representation of system structure and behavior
•Language: A language, not a methodology
The UML is neither a methodology (waterfall, UP) nor a programming language (C++, C#). It is a modeling language that provides a language-independent, tool-supported, well-documented standard for modeling systems.

There are few misconceptions about UML that I have found in my working life.

Some people take it so lightly that they think UML is so easy thing that one can do all the diagrams in a day (modeling a complete system in a day!!). Well, drawing is easy but it all depends on your concept that how you are modeling it. For an example, drawing a use case is a peace of cake, but you have to first identify a proper use case or putting few classes and connecting them is easy but the important thing is to identify classes. So you have to have complete sense of the system in concern.

Some other people take it so heavily that the think you have to do all the diagrams to model every aspect of system behavior all the time as part of a complex, cumbersome approach. This is not true. Simply make intelligent choices about what works for you. The UML is designed to serve you, not the other way around.

I have found following diagrams most usefull for any project;
•Use Case Diagram (behavior)
•Activity Diagram (behavior)
•Class Diagram (structure)
•Sequence Diagram (behavior)

In my next publish i will be discussing about the benefits of these diagram.

Let's talk about agile method

Agile method is a framework concept, generally centered on iterative and incremental delivery of working software. It is iterative because we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features.

Several agile methods exist. Some of the more well known include extreme programming (XP), lean software development, Crystal, DSDM (Dynamic Systems Development Method), Scrum, and feature-driven development (FDD). What they generally have in common is the IID aspect, but more importantly they hold similar values and principles. I've listed a few things that each method emphasizes:


Lean - Move closer to customer, shorter cycles, eliminate waste, decide as late as possible, empower the team, build in integrity
DSDM(my favourite) - Empower the team to make decisions, emphasize frequent product delivery, integrate testing throughout, promote collaboration and cooperation between all stakeholders
FDD - Center development around the feature, create a domain model with domain experts
Crystal - Emphasize people, gather techniques from other methods, improve communications, adapt the process itself (shrink or grow to fit)
Scrum - Manage a prioritized list of requires on a product backlog, collaborate through daily standup meetings, exhibit the product upon iteration completion, use retrospectives to correct the process
XP - Emphasize the values of communication, simplicity, feedback, and courage; use specific technical and collaborative practices, including TDD, refactoring, pair programming, continuous integration, open workspace, and automated acceptance tests

Original post by Jeff Langr

Impact Ranked Obstacle Analysis (IROA)

Thanks to Mr. Vic from London Metropolitan University for what he has taught me about Obstacle Analysis. After two years of classroom education now I really think that the Business/System Analysts should do some obstacle analysis in an organized way.

Obstacle Analysis is a technique used to identify obstacles to goals being fulfilled in goal directed requirement engineering as goal directed requirement engineering only focus to produce goals for the software system. There are few approaches for obstacle analysis but I am only going to describe what I think is easy to understand and use and that is called IROA approach. The approach is based on two heuristic.

Heuristic A: There is at least one group of obstacles for every requirement. These are obstacle found by negating each assumption made about requirement.

Heuristic B: The failure of an external entity or actor to behave as assumed could cause an obstacle to that assumption.

Heuristic A & B will be used in facilitated workshop (JAD workshop) for finding obstacles to assumptions made about requirements. Further heuristics will be defined as the work progress.