First drop of "TMap for VS2010" available on Codeplex
A structured test management process template for VS2010…
Still a lot to do to get it at the quality level we want, but this is a preview and as I call it… for discussion purpose only.
The planning is to get it somewhere next week at a level we can call it beta and ready for us within projects [we want to get RTM when VS2010 gets the RTM state].
The best way to get started, to get familiar with TMap and the process template for VS2010 is to take a look at the documentation. The documentation behind the template contains an almost completely filled wiki, how to execute a high quality test management approach with VS2010. Also the main reason it was that quiet on this blog lately, I created more then hundred pages of content in the documentation section of the CodePlex site. [which also can be downloaded for onsite guidance]
The actually process template is connected with this wiki and specific work items and work streams redirect to the specific topic.
Feel free to leave any comment you want, but don’t forget its work in progress there are still numbers of holes in the template, the guidance, the reports and so on…
location: TMap.CodePlex.com
VSTS 2010 TMap Process Template 1,2 and 3
As probably everybody already know, Microsoft is going to deliver a toolset for the tester with Visual Studio Team System 2010. If you didn’t know this, you can start by reading several previous posts on this blog, on Rob’s blog or on Bing. It’s not only going to support development testing or system testing but the whole stack of the testing practice including acceptance testing [manual testing].
This support for all the different test tasks by VSTS 2010, combined with the power of TFS 2010 to guide processes and Sogeti’s method for structured software testing ‘TMap’ is a major win to the application lifecycle. To get this structured software testing method ‘TMap’ into TFS2010 we made a process template.
Now it’s a bit useless to deliver a process template only for the testing practice, although there are situations where it can be used. But, mostly the conditions are that testing practices are executed during the software development lifecycle. This is a big challenge when offering a method for structured software testing, needs to fit the software development lifecycle.
This challenge is also in place with the Secure Development Lifecycle Process template. The SDL team made template for secure software development, what is really great, but actually every software development process should be secure. So secure processes should be merged with existing templates as Brian Harry writes in his post “The Microsoft SDL Process Template and the Future”
I think everyone understands that we don’t just want “one template for secure software development”
The same counts for testing. There is one big problem in this situation… process templates don’t merge very well. So, what we did to deliver TMap to VSTS2010 is creating more several templates.
First a standalone template. I know it’s useless in most situations, but for example when a customer want to manually test the application disconnected from the development team another situation where you can use a standalone template is in our test lines and StaaS offering, both situations where we are testing [manually] the application disconnected from the development environment, but with a TFS connection.
The second template delivery we made is a combined one. TMap processes combined with the In-the-box MSF/ CMM templates. Now I know nobody uses these templates without editing them. But, by providing a combined version people / companies who do a small edit on the existing [in-the-box ] templates can use these.
The last delivery is a bit more challenging and we didn’t finalize this one yet. We are delivering the XML so you can manually merge the TMap processes with your own template.
- Standalone TMap process Template.
- Combined TMap processes with the MSF Agile and CMM process templates.
- TMap processes merged with any existing templates.
Which one would you like to use?
[next post, what's in it…]
Collaborative Knowledge Sharing and Decision Making…
Nice article by Gartner and fits partly in the presentation Edward and I gave yesterday for SDN; having guidance in VSTS2010 for you design and architecture process as I call it “Collaborative Knowledge Sharing and Decision Making”…
These are the Key Findings of the report, its interesting to read them with software architecture process in mind:
- CDM is a category of decision support system for nonroutine, complex decisions that require iterative human interactions.
- Social software extends the collaborative decision-making process by allowing decision makers to discuss an issue, "brainstorm" options, evaluate their pros and cons, and agree on a course of action.
- Tagging the decisions made in social software with information from BI systems enables users to be informed when decision-making assumptions change.
- Ad hoc tagging regarding value, relevance, credibility and decision context can substantially enrich both the decision process and the content that contributes to the decisions.
Storyboard: Architectural Inspections - VSTA2010 - AppArchGuid
The result of some brainstorming with Edward about implementation details of Architectural Inspections: Implemented in Visual Studio Team Architect 2010.
Beside that the result is nice [we think and next SDN Arch event we will show some pieces], I really like the pictures taken with my Canon D40, probably will use them in our presentation.
The ALM Man…
Very funny… A 10 minute guide to how software applications are developed
Application Lifecycle Management and a Collaborative Culture.
I had some interesting discussion last week about working together and ALM, based on what I wrote in this post Visual Studio Team System 2010 – Episode 3: The Lifecycle;
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
Now I’m not a Team Dynamics nor a behavioral specialist. But, I did some investigation according these topics past year for the Cloud Collaboration Book we have written.
A big word in the Book TagCloud is ‘Collaboration’ [made by wordle.net]
So, I thought [also as a trigger for the book :-) available on Amazon somewhere in March] let’s take the intro of the chapter which talks about this. The topics and main concerns fit perfectly on ALM culture.
Creating new modes of collaboration supported by technology can only be done by addressing the human aspect. More specifically, we need to address some of the worries and obstacles people encounter when collaborating using technology.
The three most important concerns are:
Trust. Trust is a condition for social interaction. People will only work with people, companies, tools and information they know they can trust. Before we can expect collaboration to take off online, there must be a way for people to get this “trust.” And a topic closely associated with trust when it refers to people is Identity.
Collaborative culture. If one individual is the greatest collaborator in the world, he or she is probably not getting anywhere. Only when all people involved are part of the same collaborative culture will new levels of creativity and productivity be reached. A collaborative culture consists of many things, including:
- Collaborative leadership;
- Shared goals;
- Shared model of the truth; and
- Rules or norms.
Reward. Changing the way people work takes effort, so it must be clear for the parties involved what they will gain, at a personal level, from collaborating in a new way. Surprisingly, a “reward” for successful collaboration is most often of a non-financial nature.
“The ways that people work together shift over time, which can affect your culture of collaboration. More important, the introduction of collaboration technologies can also change the culture of collaboration. If handled properly, the tools and the culture will coevolve.”
Dennis Kennedy
Visual Studio Team System 2010 – Episode 3: The Lifecycle
Previous episodes:
In the last episode Rob talked about the main challenges of testing, and not only for the acceptance tester but all the roles who are responsible for the quality of the product and that's actually everybody.
No Risk- No Test… what needs to be tested, when there is no business risk there is no reason to test, no reason to make unit tests by the developer, no reason to make regression tests and no reason to do acceptance testing. But when there is a risk every role has the goal of making that risk as small as possible. There is a joined effort in execution of tests to prove that the risk is minimized or solved. The development testers, system integration testers and acceptance testers together have to make a strategy on how to test.
Application Lifecycle Management
When talking about Application Lifecycle Management [ALM] terms like accountability, governance and compliance are used. All of them refer back to “working together”, how do we work together during the application lifecycle. ALM is not about tools, it’s about working together. Working together seamless and flexible while staying in control, being measurable and responsible. All the roles in the application lifecycle have a part in this collaboration effort. Tools can help but isn’t’ the core driver.
There are lots of examples of wrong interpreted business requirements, miss communication between development en test [Rob describes a very real example], applications which won’t run in production, operations who don’t understand the applications. All of them resulting in more work, more faults, more costs or even only costs and no application because the project was unplugged. Most of these projects faults, these extra costs are a slip in communication.
Having a strategy how people have to collaborate within the lifecycle is one important piece of Application Lifecycle Management. Most organizational parts have already some kind of process / methodology in place. Having an approach how to share information and share ideas from their own role point of view through the other roles is a key success factor for lowering the costs and raise the business value of IT investments.
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
Before ALM…
In the early ages, the waterfall ages, nobody talked about Application Lifecycle Management. Software development was still in his youth, experimenting with proven processes from the industrial age. The era where Taylor educated managers controlled the workforce. Business people writing down what they want [not knowing what they need] and throwing their needs over the wall to the workforce.
There was no communication between the guy who needed the software and the guy who implemented the software, a massive brick wall separated them. All the roles in the Application Lifecycle did their job between walls. People where used to this formal way of working, not arguing, not discussing about the solution, be doing their job as optimal as possible.
It doesn’t need any explanation that this Taylor way of work didn’t work for software development. Some software projects succeeded but many more failed to reach the goal. The main reason why all those projects fail: there was no sharing of ideas, ideas how to achieve business value. Everybody was working in his own domain with their own specific tools, as shown in the picture below, everybody on his own island with his own specific tools, practices and methodologies.
Software development is way different than producing products [Taylor’s theory is about optimizing the work force, something Ford did very well]. Software development needs a shared effort, a shared effort by all the roles in the lifecycle. From the people who have the business ideas and knowledge to the people who have to implement, test and maintain the final solution. Everybody in the lifecycle needs to collaborate with each other. Everybody needs to add their specific knowledge to the solution, that's not the same as adding parts to a car.
It’s interesting to notice that when there are no guidelines / structure in place, and nothing is done to stimulate collaboration. People and groups of same interest starting building their own walls, building their own kingdoms, protecting their environment. So, if we want to change this cubicle way of working, management buy-in needs to be in place, groups aren’t going to collaborate automatically.
Now
Nowadays, everybody understands that communication is king. Roles in the lifecycle need to communicate, need to listen to each other and share ideas about their view on the solution. The Agile methodology gives guidelines and structure , with valuable principles like:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Tooling starts to support these principles [and the other 17] adopting a new way of communicative work around the Application Lifecycle. In 2005 Visual Studio Team System starts to support these principles. The integrated development environment got supported by Team Foundation Server with workitems, process templates and reports, helping to get roles in the lifecycle to communicate in a more efficient manner. Integrated in one tool people can share their workload and workprocesses, giving the project leader and for sure the other roles the ability to have more control over the process of software development, by knowing what the other one is doing.
Telling each other what you are doing is challenging. It’s challenging within a group of people with the same interest, it’s even more challenging between groups of different interests. It’s a culture challenge to get it working. Everybody knows it’s valuable, but most don’t want to give someone else a look in his kitchen. It’s valuable because it give transparency, agreements are known, even if someone is working according to this agreement and people can more easily get in sync. Everybody gets the focus on the business target.
[A dependency diagram of RUP’s process components.]
That people need to work together on a process and workitem level isn’t that strange when we look at the above image. This is a visualization of the degree of coupling between different process elements in the RUP methodology. …A Rational Unified Process (RUP) Plug-in To Support Requirements Quality Assurance [pdf]
The figure shows, that there is a very high coupling for approximately one third of all process components. 21 process components have a coupling less than 25%, 8 process components have a coupling of more than 25% and 3 process components more than 40%.
It’s interesting to notice that the adoption of workitems and processtemplates, although they are valuable, within companies fail. The main reason is the culture of the organization and management which doesn’t fully supports communication. This cultural aspect of communication between different roles, different social groups, should have a main focus while implementing Visual Studio Team System, otherwise success isn’t guaranteed.
This is also recognized by agile gurus like Scott Ambler who is writing in his blog:
Your existing culture and organization can really hinder your ability to scale agile approaches,
In his book “Agile Database techniques” he talks about The Cultural Impedance Mismatch between Data Professionals and Application Developers, discussing the cultural problems according to the communication between database people and code ‘object oriented’ people.
Overcoming the cultural impedance mismatch is much more difficult than overcoming the technical impedance mismatch. [The Cultural Impedance Mismatch Between Data Professionals and Application Developers]
The collaboration starts
While VSTS 2005 and 2008 support communication at a workitem level, the 2010 version of Visual Studio is going to support collaboration at artifact level. Different roles in the lifecycle work together on artifacts. Each of them adds their knowledge, vision and ideas to the solution from their view point. These artifacts are accessible by every role in every phase of the project, adding value throughout the lifecycle.
People are enabled to collaborate, making applications together, and not only by telling what they are doing but most important by working seamless together on the application.
While working together with all the roles and having these ‘ALM’ artifacts accessible for every role, collaboration in the application lifecycle will rise to the next level. People with different social and cultural characters start discussing solutions, trigger each other to improve and being innovative with their view on the application and all within the constraints of their role.
VSTS 2010 enables people to collaborate on artifacts in the Application Lifecycle. While the 2005 and 2008 versions mainly focus on communicating about work [workitems , processes and reports]. With VSTS 2010 the focus moves on to collaboration on artifacts. The main reason this is going to be possible is the investment by Microsoft in the Architecture Edition and Test Edition, widening the scope from developer to more roles in the lifecycle.
Not only development artifacts like source code can be saved to a repository but also test artifacts like test cases and test results. they can also be saved to the same repository, creating the possibility to work together on these artifacts from the same repository.
Testing in the Lifecycle
To figure out how this all works with testing we need a deep dive in the different test roles, what they do, what way they work together with the other team members and what kind of capabilities they need from the tools they use. Rob already talked about the different test roles “developers who are testing, specialist testers during system testing or generalist testers during the final acceptance test”. How do all these test roles work together with for example the business to capture risks of the system?
In the next episodes we will discuss these different test practices what they patterns are and the capabilities the need from tools.
Visual Studio Team System 2010 – Episode 1: A Focus on Testing
An intro from the VSTS 2010 data sheet:
[VSTS 2010 new functionality focuses on the architect, designer and test rolls in the Application Lifecycle]
This series will focus on the test roll; which flavors are there, what do they do, what are their goals, what do they do to reach that goal, how do they collaborate with other rolls and in what way does VSTS 2010 support their activities.
In what way can a collaborative effort in test activities support the business goal? Visual Studio Test Edition offers several new possibilities according to testing in the lifecycle and with the interaction between the tester and the other rolls in the lifecycle.
[Tests in the Lifecycle]
In the early and current edition of Visual Studio Team Test there are already several testing features available, helping the developer with test driven development, performance testing, load testing and several more [see this MSDN page].
While the current version of the Test Edition focuses on the roll of the tester and their activities, Visual Studio Team System 2010 is focused on the collaborative effort between the tester and the other rolls in the application lifecycle.
[Camano, VSTS2010 Acceptance Test Tool]
The most visible feature is Camano, a standalone acceptance test tool. This tool connects with Team Foundation Server and the newly introduced workitemtype ‘test case’. Workitems aren’t the only integration with the rest of the lifecycle, Camano also create automation strips which can be used during the ‘readiness scan’ [the system / integration test phase of the lifecycle]. Both possibilities of Team Test give the tester a stronger connection, a better collaboration with development. Another addition which stimulates the collaboration is Lab Management [see this screencast on Channel9]:
…lab management, which leverages virtualization to enable software development and test teams to build higher quality apps. Lab management accelerates setup/tear down time and eliminates no-repro bugs by creating better integration across dev and test teams throughout the application lifecycle.
[Lab Management]
These new capabilities will help fixing some major challenges in product development, they will save time and improve the quality of the overall product. Analyzing and fixing a bug is, without doubt, a loss of time. And the later the bug is found, the greater are the losses. Finding bugs AEAP (As Early As Possibly) becomes more and more important, especially in the complex systems we make nowadays. The joined knowledge together with integrated tooling of the developer, the tester and the architect/designer can help with this challenge. But, having tooling in place which help the tester to their job more efficient isn’t enough for a good test process. Testers can still just test one button, one screen or even the wrong functionality or do it the monkey way.
[Monkey Testing]
How good is your test process? This seemingly easy question turns out to be very hard to answer in reality. Testing is often experienced as a troublesome and uncontrollable process. Testing takes too much time, costs a lot more than planned, and offers insufficient insight in the quality of the test process and, therefore, the quality of the information system under test and the risks for the business process itself.
The Test Process Improvement (TPI®)-model offers insight in the 'maturity' of test processes within your organization. Based on this understanding the model helps to define gradual and controllable improvement steps.
[TPI® levels mapped on IO model]
Collaborative, efficient tooling together with a mature structured test approach will not only result in better quality software but also gives the Application Lifecycle a way to improve the software delivery process. The responsibility of testers is not only finding bugs, but also to initiate learning cycles. They know where things go wrong.
In the next episode Rob will guide us through the world of testing…
Some thoughts on Structuring modeling projects in Visual Studio Team Architect.
The success of using models [UML and non-UML] in the application lifecycle dependents deeply on how you’ve organized them, and with that also the success of the solution you are going to deliver.
Models [mainly the UML ones] are used for communication. Communication with different shareholders how the solution looks like and to discuss how the different concerns and needs find their way in the solution. But also to communicate with developers, testers, operations, designers and many more.
[A like this picture of different types of stakeholders, from the change management toolbox ]
Communication, Keep it simple.
The most important thing you have to think of when you want to communicate something with someone is to be clear..! With models this means; clear in language use, so people understand the models. Avoid jargon and overuse of big words.
As the poet William Butler Yeats once said:
Not only be understandable in language but also be clear and self explaining in the organization of the models, so people can find their way in the solution. Just as the basic rules used when writing and article or book.
Organization Maintain a logical order or sequence. Paragraphs should deal with one subject. Logical transitions should be made within sentences and from paragraph to paragraph. Make sure introductions and conclusions are evident. Make it easy on the reader to see your point of view by guiding them logically down a path.
With this in mind, lets organize some thoughts how to structure the modeling effort.
I almost forgot one thing many people, organizations trying to accomplish with the use of models traceability. Traceability of requirements top–down and traceable from bottom-up. Traceability is an interesting goal, a hard to reach goal but we can keep it in mind will organizing our model structure.
The Default Modeling Structure
Lets call it default, because the most common way to group diagrams is in levels of abstraction [Business, Analysis, System and Implementation, see image below]. And within this grouping models are often divided in scenarios, userstories and components, subsystems, sometimes grouped by iteration [see analyses and system model]. 
Having the models structured in this way makes it easy to understand at what kind, what level, you are looking. for example when you want to know the overall
meaning of the system under development, look in the Business Model folder. When you find the piece what’s interesting for you step one folder lower and look at a more detailed level in the analysis model. You can walk down till implementation level, the code and corresponding class diagrams. [with VSTA’s designer bus this should be even more easy]
You also see structures where the analysis model and system-design model are divided in scenarios grouped by iteration [I call it system-design model because the other part of the system model is the high level architecture/ software architecture, see image]. Grouping these two models together gives an easy way to find the meaning, requirements and the corresponding design of components, useful when you have a lot of components and subsystems with many functionality [also called vertical grouping].
Possible artifacts.
Possible, because every project is different and with every project we must think about the structure modeling method, what models are needed and even more important which models are useless.
The Business Model, meant to get business-driven requirements and set boundaries, is not always necessary. Within big companies with mature enterprise architecture skills this is often already defined and is the input for the project. [The Enterprise Architect and the Application ]. But, it’s still very useful to have this information in the solution and not somewhere on a portal, teammembers will have easy access to the “business / why this project” information. And the business models are input for the analysis models. Often used models are: Business Use Cases [Capturing business requirements using use cases], Business Activity Diagram [and-or state chart], and Business Object Model [Class diagram]. When the Business model is in place [and additional information like a glossary], you can define the key usages scenarios for the project.
The Analysis Model, captures more detailed requirements, user stories and/ or usages scenarios [depends on what methodology your team uses]. From the key scenarios found during business modeling, capture the more detailed use cases, activity diagrams and domain model. Just enough information to get an understanding how the high level architecture should be modeled in the System Model. Traceability between the business model and analysis model is easy. the same kind of diagrams are used and the information is just a bit more details in the system model than in the business model.
From the, kind of, requirements gathering models we get at the level of defining our system. The Application Architecture Guidance from the Patterns and Practices group gives a nice overview of this process [see image]. A must see is the video they made. Within the System Model there are two different models [or more] the first is the high level architecture which gives an overview of the system. Component diagrams are often used at this level and also the layer diagram [ the deployment diagram isn't available in VSTA but should also be used at this level]. This high level architecture sets the technical boundaries of the system from where the other parts are designed. I call it the System Design Model, this is where scenarios, requirements who need more designing because they are hard to understand, difficult to implement or some other reason are modeled. Also by using component diagrams, layer diagrams, class, sequence… you name it. so that’s the reason why I divided this system model in two parts.
The thick red line between Analysis model and System model is there because traceability between these two artifacts is hard, two different things get modeled [requirements versus system] and with different diagrams. A thing often done to validate the system design is replaying the key scenarios with a sequence diagram at component level. The Implementation Model is actually the code and the diagrams who live very near the code like class diagrams. As you can see in the Solution Explorer image I called this folder ‘Source’, because that's what we used to do. Also between System Model and Implementation Model a red line and hard to organize traceability for the same reasons. Although the layer diagram with the architecture validation capability makes it easier to get a connection between these two.
4+1 View
The 4+1 View is something everybody learns on school as a way to describe an architecture of a system. This view model designed by Philippe Kruchten defines it’s views based on the viewpoint of different involved stakeholders.
http://en.wikipedia.org/wiki/4%2B1
The scenarios [use case view] are the reason for the system and all the other describe the system, that's way the +1. You can structure your models based on this viewpoint model. Mapped on the ‘default’ structure described in the previous paragraph, it would look something like this; The business model and analysis model are the scenario’s. The system model can be mapped to the logical view, although i do think the logical view as described in the different books has a bit lower abstraction level than the system model as described in the previous paragraph. The logical view can be structured in a horizontal way and a vertical way.
Vertical and horizontal divisions
The application can be vertically divided into significant functional areas (i.e., order capture subsystems, order processing subsystems).
Or, it can be horizontally divided into a layered architecture distributing responsibilities among these layers (i.e., presentation layers, services layers, business logic layers, and data access layers).
[whitepaper [the pdf ] from Sparx]
In the example structure I divided it in functional areas. The process view together with the Logical view are at a conceptual level while the other two [development and deployment [physical]] are at a physical level. In the ‘default’ and in the example structure, the process and logical view are grouped in functional areas, you also can divide them in separate folders. The other two ‘physical’ views is the implementation model, although Visual Studio Team Architect 2010 CTP doesn't have a Deployment diagram [yet..? ]. The development view is the source folder in the example structure, because the class diagrams in team architect are coupled in someway [actually there are two different class diagrams within VSTA, the very tied coupled which is actually a visual representation of the code and the loose coupled logical class diagram from where you can promote classes to the physical level] with the sources. You could make a separate folder for the implementation model / development view and use that one for the logical class diagrams and put the physical class diagrams near the sources. Not a very clear structure, in that way you put the same information two different places.
Actually we made the ‘default’ structure in a 4+1 way. So, when the environment/ customer wants a 4+1 just change the names ;-).
Breakdown
It is possible to make one big diagram in each model, one big use case diagram in the analysis model and one big class diagram in the system model. The pro is that you have everything, all the information together in one place, the con is you need a A-1 plotter and a big wall where you can put it on, beside this con there are many more cons than pros.
[not a class diagram, but a generated Web Service Software Factory servicemodel from a Amazon webservice, see this old post]
When there is just a single owner and editor of the diagram it can be done, one big diagram, beside it’s unreadable for the users. But, when there is more than one editor you get in to problems, merging problems. I change a reference to an object and somebody else removes that object… what should happen when both of use check in the diagram? So, one big reason to breakdown your models is merging. Another reason close to merging is you must be able to change your diagrams in an easy way [ready for change]. Within one big model it’s first hard to find where you need to change something and second it’s even harder to find the dependencies. And I think when you breakdown your models, you also think about important architectural guidelines, like functional cohesion, ownership and loose coupling. For more key design principles, see the application architecture guid, Chapter 3 – Architecture and Design Guidelines.
Some more Thoughts
To get the models and modeling content organized in a way so it’s understandable, simple and ready for communication is hard. Writing a book is hard, getting the structure of the book right is even harder, but getting it right for a software solution is even more troublesome, there are that many different dependencies you have to take in to account that there isn’t an one solution fits all. But not to get depressive, we can have a look at the most important ones and find a solution.
This image from the book “Getting Results from Software Development Teams by Lawrence J. Peters” gives a nice overview of the Modeling Method decision making.
The author described in this chapter also challenges in adopting a Modeling Method, interesting reading. One of the inputs for the modeling method is the type if system to be modeled.
Dependency; Architectural Style, [Type of System].
This is where the The Architecture Meta-Frame found in the Application Architecture Guidance V2 comes very helpful. It describes the most common application types and architectural styles, every type has it’s own pros and cons, but also every architectural style has it’s ‘preferred’ way of structuring the modeling files and projects.
An architectural style is a collection of principles that shapes the design of your application. Many of these styles overlap and can be used in combination. Architectural styles tend to be tied both to the application type and to the point in time in which the application was developed.
Because the Business Model and Analysis Model are a kind of solution independent there will be not much difference needed in the structure. [’Kind of’ because different architectural styles can result to different requirements]. The system and implementation models will have a dependency with the architectural style. For example a Client Server style solution often exist out of database which runs on a server [or in the cloud] and some kind of client application type. The client application is most often divided in to layers. the requirements gathering models will probably stay the same but the system model will have additional diagrams, for example the logical data diagram and for sure the breakdown of the diagrams will be different.
In the client server example you will definitely have a client and a server part, where the server part is the logical data model and the database diagrams. With an N-tier architectural style you probably will break down the models in tiers [difference between distributed deployment, non-distributed deployment], while with a SOA style there are many separated services with some kind of layering and some kind of Business Process Model.
Dependency; Team Organization.
There are team scenarios which influenced the structure of the models. The most simple team structure is just one team working on one project, see image below in this situation the default model structure can be used. Everything is available in one solution, every roll can access the information needed to do his job.
As you probably notice I derived the model structure image from the TFS Guidance from the Patterns and Practices group. See this chapter of the guidance. I’ve added the modelprojects to it. When the system model contains an VSTA Layer Diagram we can validation if the refereneces between the projects defined in this layer diagram are the same as the real world.
It gets more complicated in larger projects where a partitioned solution structure is used [again see TFS Guidance]. Within the development department of an insurance company, for example, there are probably many teams working on different applications/ services or different versions of an application. Communication gets even more important when different projectteams have dependencies with other projectteams [image below and this post VSTA, the enterprise architect and the application lifecycle and this too old post Autonomous Develop Services for SOA Projects with Team Architect and Service Factory].
This large development project is divided in several solutions, because their is still one business demand there is just one business model in the master-solution, and one system model [the HLA part see first paragraph] that gives an overview of the structure of all the child-solutions and their relations. Probably [hopefully] during the breakdown is taken care of the architectural guidelines mentioned in the ‘breakdown’ paragraph [functional cohesion, ownership and loose coupling], so the child-solutions can have their own analysis, system [the lower part] and implementation models.
One project team opens his child-solution and want to start defining it’s implementation model, layers, components and classes, what kind of information do they need? first the analysis model to get information what should be build and second, the dependencies [the interfaces] with the other projects. This information is available in the master-solution but it would be inefficient when they also had to open the master-solution just to get a view of the relations. So, a better way should be when with the child-solutions also contains the two modeling projects [business model and system model] from the master-solution. A very easy way to accomplish this is with the add existing project menu-item. One big benefit of adding the business and system model to the child-solutions is that the elements used in these diagrams appear in the model explorer and can be re-used in the child models.
 |  |
| Master solution with all the child projects, the Business and System model named the High Level Architecture. | A child solution with at the right the child analysis, detailed system and implementation models… and the embedded master business / system HLA… which show up in the model explorer for reuse. |
The very large project is actually a combination of ‘normal’ projects and ‘large’projects. Although the solutions which have an dependency are still troublesome and should be build in the order of dependency… see image form again the TFS guidance.
Dependency; Methodology.
CMM vs Agile… a big difference, see Agile Modeling for details.
pfff… don’t feel like typing any more, the story got a bit longer than I wanted... but will be continued, because this also opens opportunities for the Blueprints [see the posts I did with Edward].
One final quote:
The essence of "good design" is it's ability to be absorbed by a human mind. Design is "good" when it can be easily-learned.
...
Good design is about knowledge. We wrap it up in all kinds of terminology, but in the end it's about making smallish bits of software that are easy to understand on their own, and that fit together exquisitely to make things bigger than themselves, and that can still be as easily understood.
"Good Design" Means ...?
Getting App Arch Guid Knowledge in VSTS2010 – Part3 Create Diagrams from Code
The (experimental) journey of getting App Arch Guid Knowledge in VSTS2010 with Edward continuous…
previous steps…
- The VSTA Layer Diagram and the P^P App Arch Guide 2.0.
- Blueprints: Visual Studio 2010 CTP
In this step as promised in part 1 ‘Create Diagrams from Code’.
I used VSTemplate and the IWizard interface for the first solution, but now we have the Blueprints available in VSTS2010 we better can use that functionality to create the diagrams. For this post it actually doesn’t matter what you use as long as you can access the Visual Studio automation object model [DTE].
The steps you have to take.
- Get and Load the Model and Diagram.
- Get the Store and start a transaction.
- Create the shape.
- Create the ModelElement and associate it with the shape.
- Add the combination to the design surface [diagram].
- Add child's [nested shapes] if necessary.
- create the dependencies.
- commit the transaction.
- save the model and diagram.
In more detail.
Step 1. Get and Load the Model and Diagram.
1: LayerModel layerModel = LoadModel(dte.ActiveDocument.FullName);
2:
3:
4: private LayerModel LoadModel(string fileName)
5: {
6: LayerModel currentLayerModel = null;
7: Store store = new Store();
8: Type[] modelTypes = new Type[]
9: {
10: typeof(CoreDesignSurfaceDomainModel),
11: typeof(LayerDesignerDomainModel)
12: };
13: store.LoadDomainModels(modelTypes);
14: using (Transaction t = store.TransactionManager.BeginTransaction("Reading diagram"))
15: {
16: currentLayerModel = LayerDesignerSerializationHelper.Instance.LoadModelAndDiagram(store, fileName, fileName + ".DIAGRAM", null, null);
17: t.Commit();
18: }
19: return currentLayerModel;
20: }
line number 1 is the calling method to the loadmodel function and as you can see i open / load the current in visual studio activated document, you can grab any diagram file. the first thing to look for [using reflector] are the modeltypes when loading a different kind of model. because i not only want add modelelements but also want to control the place of the shape on the design surface i have to loadmodelanddiagram. the .diagram file has knowledge of the position and the .layer file of the modelelements.
Before I forget it the usings are a bit tricky in this ctp. you have to add a reference to “microsoft.visualstudio.modeling.sdk.10.0” and “microsoft.visualstudio.modeling.sdk.diagrams.10.0” [and some more]. the problem is that these aren’t visible in the add reference dialogbox. so, you have to add these manually by adding them in the csproj file.
1: <Reference Include="Microsoft.VisualStudio.Modeling.Sdk.10.0, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
2: <Reference Include="Microsoft.VisualStudio.Modeling.Sdk.Diagrams.10.0, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
the other references […teamarchitect.layerdesigner and …teamarchitect.layerdesigner.dslpackage] you need can be found in ..\..\program files\microsoft visual studio 10.0\common7\ide\privateassemblies\
Step 2. get the store and start a transaction.
1: Store store = layerModel.Store;
2: using (Transaction t = store.TransactionManager.BeginTransaction("Draw diagram"))
and now we can start to create shapes and place them on the designsurface.
Step 3 and 4. Create the shape, modelelement and combine them.
1: LayerShape layerShape = new LayerShape(store, null);
2: Layer layer = (Layer)store.ElementFactory.CreateElement(Layer.DomainClassId);
3: layer.Name = name;
4: layerShape.Associate(layer);
set some visual properties of the shape, you can completely tweak the looks of the shape.
1: layerShape.AbsoluteBounds = new RectangleD(0.5, 0.5, 7, 2.375);
2: layerShape.FillColor = Color.DarkOrange;
repeat this for all the layers you want to create… and after that
Step 5 and 6. Add them to the Model and Diagram and – or create nestedchilds.
1: diagram.NestedChildShapes.Add(layerShape);
2: layerShape.NestedChildShapes.Add(uiProcessComponentsShape);
3: LayerHasChildLayers child = new LayerHasChildLayers(PresentationPair.LayerPart, uiComponentsPair.LayerPart);
You have to tell the Model and the Diagram that they are nested… if you tell it only to the Diagram [visual layout] they look like if they are nested but in the Layer Diagram Explorer you can see they aren’t.
Step 7. Create the dependencies.
1: DependencyFromLayerToLayer dep = new DependencyFromLayerToLayer(PresentationLayer, CrossCuttingLayer);
Step 8 and 9. Commit transaction and Save the Model and Diagram.
1: t.Commit();
2: }
3: SerializationResult result = new SerializationResult();
4: LayerDesignerSerializationHelper.Instance.SaveModelAndDiagram(result, layerModel, dte.ActiveDocument.FullName, diagram, dte.ActiveDocument.FullName + ".DIAGRAM");
Conclusion.
There is one big drawback with this solution. Because I load the model and diagram from a file, change it and save it back to the two files, Visual Studio recognizes that they are changed outside the IDE and popup a message [two times] if you want to reload it. Not something you want. A solution for this could be the Backplane. Edward did some early investigations around the backplane last year and the layer diagram is connected to the Backplane [not all VSTA diagrams are]. So, that would solve the reload problem. But, that’s something for another post… first Merry Christmas and a Happy New Year everyone, till next year..!