Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
If you had to create a list of steps that a non-technical business layperson would understand for implementing workflows in something like Mule ESB -- what would it look like? The scenario would be to describe how the ESB is used to perform integration between two disparate systems and the steps you would need to perform to get the job done.
An Enterprise Service Bus is a technical middleware for system integration. It is doubtful whether mixing the business aspects into the picture makes sense. For business people to look at a picture and 'get it', the technical aspects would either be abstracted away and or require a tacit understanding of the technology. Better to keep them separate.
On the business logic level you should use BPML for workflow modelling:
http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
The technical aspects of a service bus are captured through Enterprise Architecture Integration patterns:
http://www.eaipatterns.com/toc.html
The EAI view is already abstract, but expecting business people to understand this is like handing them UML diagrams and assuming they're literate by nature (alas, they are not).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a large legacy .NET application that has evolved and grown over the years to include many components and moving parts. I want to develop a strategy for developing automated unit and integration tests for this application and to that end I think a graphical representation would be key.
What I am picturing is some sort of diagram I could use to guide the process of writing up the test cases, help achieve better coverage, and eventually refer back to once a specific test fails. Does anyone have any thoughts on what type of diagram could fulfill this goal? My guess is this would be a variant of the classic functional block diagram, but I have not found examples that specifically relate to the design of an automated testing strategy.
Could this be what you are looking for?
The UTP provides extensions to UML to
support the design, visualization,
specification, analysis, construction,
and documentation of the artifacts
involved in testing. It is
independent of implementation
languages and technologies, and can be
applied in a variety of domains of
development.
UML Testing Profile: http://utp.omg.org/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Thinking about service orientation, our team are involved on new application designs. We consist in a group of 4 developers
and a manager (that knows something about programming and distributed systems). Each one, having own opinion on service design.
It consists in a distributed system: a user interface (web app) accessing the services in a dedicated server (inside the firewall), to obtain the business logic operations.
So we got 2 main approachs that I list above :
Modular services
Having many modules, each one consisting of a service (WCF).
Example: namespaces SystemX.DebtService, SystemX.CreditService, SystemX.SimulatorService
Unique service
All the business logic is centralized in a unique service.
Example: SystemX.OperationService. The web app calls the same service for all operations.
In your opinion, whats the best? Or having another approach is better for this scenario?
A web service is an interface. The invoker doesn't care how a service works, it just needs to know what arguments to supply and what outcomes to expect. So a multitude of simple, discrete servcies is probably better.
Behind their interfaces they can all join up in one great big bundle of business logic. Who cares?
In practice, teach of hese services will share some elements of SystemX functionality and will have some elements which it alone uses. Some may combine elements of SystemX and SystemY. If SystemX and SystemY are legacy apps it may not be possible to change them, so we have to work with them as they are. In other scenarios it is possible to expose impose modularity on them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
How to write a vision [generally] for some business ? Is it have some template ? any example ?
Business about online ticket services .
What is a 'vision'?
It's such a nebulous objective... I don't see how there could be a template. Unlike requirements specifications, functional specifications etc, there is no accepted understanding of what a 'vision' actually is...
I'd speak to the person who commissioned you to write the 'vision', and ask them what exactly they are trying to achieve and what their expectations are.
Here is a nice article on the Vision. Note that it doesn't have to be a heavyweight document (spend as little time as possible but as much as required). For more formal templates, RUP has some for the Vision artifact.
Karl Wiegers' book, Software Requirements, has an excellent template. I've used in for several projects. It seems a bit formulaic at first, but over the subsequent days and months, really helps a team keep focus.
http://www.amazon.com/exec/obidos/ASIN/0735618798/processimpact
http://www.processimpact.com/books.shtml
The Business Motivation Model is a great source. They define what a business vision is, relate this concept to other relevant concepts in the organisation, and give good examples.
If you are interested in how business requirements are refined into user requirements and how, eventually, they determine what a software system does, you may want to have a look at the OPEN/Metis white paper.
First i warn you : Do not be a template zombie...
Secondly to give you just an idea OpenUP has a nice -non commercial Vision Template...
Check my answer how you can get it : RUP (Rational Unified Process)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Based on the different views documented in SAD which RUP roles should should be responsible for creating the SAD? I thought from the beginning that the SAD was only for a technical audience but from what i can see in RUP it is more than that so it seems like it is not only the Software Architect that should be involved.
Well, according to RUP's documentation, it's the Software Architect.
Quoting the Artifact: Software Architecture Document online reference:
Responsibility
A software architect is responsible
for producing the Software
Architecture Document, which captures
the most important design decisions in
multiple architectural views.
The software architect establishes the
overall structure for each
architectural view: the decomposition
of the view, the grouping of elements,
and the interfaces between these major
groupings. Therefore, in contrast with
the other roles, the software
architect's view is one of breadth, as
opposed to depth.
The software architect is also
responsible for maintaining the
architectural integrity of the system
through the development process by:
Approving all changes to architecturally significant elements,
such as major interfaces, described in
the Software Architecture Document.
Being part of the "change-control board" decisions to resolve problems
that impact the software architecture.
Well,
Do not think "roles" as job titles...
If you work in a traditonal enviroment, generally there is a guy who is job title is also "Software Architect"...If you work in an agile enviroment generally you can not find a job title like "software architect" in team...So the important thing is who knows and who gives the important decisons about architecture: Who fills the role of the architect not title....
In an healty enviromement[ traditional or agile] one guy can not give all decisons, so SAD is a workproduct of all team in practice because all teams members sometimes play the role of "architect"...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work for a insurance company. We have our own development department made-up of almost 150 people plus some providers (outsourcing and custom made apps pretty much). In our company my team have made what we call non-functional logic libraries. That is, software libraries to handle things that are horizontal to all the development teams in our department, e.g. Security, Webservices, Logging, Messaging and so on. Most or these tools are either made from scratch or adaptation of a de-facto standard. For example our logger is an appender based on Log4J that also saves the logging messages into a DB. We also define what libraries to use in the application, for example which framework for webservices to use. We use pretty much JavaEE and Oracle AS in all our organization (with some Websphere Application servers).
Much of these projects have their architecture documented (use cases, UML diagrams, etc) and generally the generated documentation are available.
Now what we have seen is that for users sometimes is difficult to use the the libraries we provide and the are constantly asking question or they simply don't use them.
So we are planning to generate a more friendly documentation for them, so my question is:
What are the best practices or the checklist that software documentation should have?
Something comes to my mind:
API Reference guide
Quick start Tutorial
API Generated Documentation.
Must be searchable
Web Access
What else should it have? Also, based in your experience what is the best way to maintain (keep it up-to-date) and publish this type of documentation?
Keep your documentation in version control too.
Make sure on every page it has a version number so you know where your user has been reading from.
Get a CI server going and push documentation to a LIVE documentation site upon updates.
Do documentation reviews like you would code reviews.
Dog-food it :)
Kindness,
Dan