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