Right Progress

News Track

A platform where employers/recruiters can post vacancies and access a large databse of resume.

A platform where job seekers can post resume and search for jobs in

Design

Application quality and developer productivity keep software development projects on track and ensure long-term stability. Disparate development project members and different code languages, however, can often derail the most organized software development project. Embarcadero Describe Enterprise solves this problem by providing a model-driven analysis, design, and development environment that leverages the Unified Modeling Language™ (UML).

Describe Enterprise reduces complexity and increases visual clarity in any type of software development project, ensuring a sound architecture is established and communicated throughout the Enterprise. Its rich feature set enables collaboration between everyone in the enterprise with a stake in the software development lifecycle, from Business Unit Manager to System Requirements Architect to Project lead to Application Developers working in Java, .NET, Visual Basic, C++, C#, and more.
Describe Enterprise provides your development organization with a “neutral” modeling platform supporting all major leading code languages including Java/J2EE, Microsoft .NET/C++/C#/Visual Basic, and others. The result is greater flexibility in new application development on the best platform to solve the business problem with no hardware or software vendor lock-in involved.
We realized that, as with software development, web development required clear documentation. We began to do rigorous documentation for our projects. I looked at many examples of technical specifications. I quickly realized that if I was boggled by these technical specs, our clients would have no hope of understanding them. We knew we couldn’t write a web site technical specification like other technical specifications because our clients weren’t technically trained.

Even when we were working for a technical client, we found that technical specifications were not an effective form of communication. While the technology folks do understand the language of the medium, they are rarely the primary person responsible for establishing goals and working through the development process. This is usually left for others, either upper management, or often the marketing department. In any case, the project leaders do not often have a strong technical background. Their technical knowledge was not deep enough to understand all the technical issues involved in the project. If you’re not technical, a written technical specification will make your eyes glaze over. Technical specifications are not at all effective in communicating to “normal people.” We had to find a way to document non-technically.

Defining technical specs non-technically

A web site is software. It is written in code, and runs on a computer. The more dynamic a site (database driven) and the more functionality it has (integration), the greater the divide between the clients’ knowledge and the product they are buying. Not many of the clients we’ve worked with have had experience purchasing and developing custom software (which is what a web site ultimately is). This creates a real barrier to smooth project management. Even if the developer takes the time to plan and document the specifications for the project, the client is often unable to understand what the technical specification is saying. The end result is miscommunication, missed expectations, project creep, and blown budgets and launch dates.

	Planning
	Design
	Development
	Maintenance

What didn't work

Recognizing the need for well documented communication written in a non technical way, we began producing what we referred to as “information architectures.” These were documents that showed generic page layouts that reflected the overall structure, content and functionality of the site. Each document page would detail the content of one web site page. They would be void of visual design but would clearly detail the site navigation, categories, tools, content and features. We would represent almost every page in the site in this way. On each page was a written description of the features for the web page it described. To make sure that the language was clear and did not assume knowledge of technical terms, the documents were written by a project manager who was not exceedingly technical. These information architectures would be lengthy, take quite a while to produce and review with the client. They did help, but when we found ourselves well into the design and development of the project, we would still find that our clients still had missed expectations. They had not understood (or had forgotten) what we had defined, and while it’s nice to have documentation to protect yourself when they forget, it still creates a negative experience. The client feels trapped and their expectations are missed. We were stuck. We began to think that there was just no way to communicate this stuff clearly enough to avoid all these problems.