When you're starting a development process, you have to start somewhere. Academic is one way to go, UML or OPEN might be a more practical way. The DAD process on gantthead might be your first step. Here are some thoughts to get you headed in the right direction.
Agile vendors have done a good job providing project managers and product owners with planning and tracking tools. But the primary creators of project deliverables are software developers, and they have consistently been an afterthought. To scale across the enterprise, Agile work processes must embrace the individual contributors doing the actual work.
Reason No. 4? Failure to adequately identify, document and track requirements. Ambiguity of requirements is like corrosion in projects, eating away at the team's credibility and at the probability of having a successful outcome. Project failure is a forgone conclusion. Or is it? What can and should be done?
Projects can be delivered without software tools, but it sure makes it easier if you have a few tools in your pocket to make project execution a little easier. Inside you'll find four key tools you can apply on everyday engagements.
Think of Microsoft's new Class Designer as UML and more.
Few know the evolution of Application Lifecycle Management and how the Structured Revolution of the 1970s and '80s was a major turning point in software development. This article presents a retrospective on ALM and Structured Development Life Cycles--those that shaped it, the influencing principles and the related methodologies and tools the movement spawned.
I am hearing lots of talk about workflow methods, process modeling and use cases. Are they all referring to the same thing, or are they distinct concepts? Allow me to clarify this confusion.
Getting in step with workflow means knowing the difference between workflow and process, and keeping it straight.
You wouldn't build a skyscraper without the right structural framework. Likewise, developing applications and systems means knowing the frameworks to build on.
There's no getting around it: Components based methods and practices are here to stay--and that may be just what project managers need to improve success rates.
Move over, project managers. There's a hotter IT job for senior PMs: Program Manager.
The secret to rapidly capturing requirements lays in understanding the business processes that the application is suppose to leverage and support. And it is in the gap between how things work today and how they need to work to achieve core business objectives that the fruit of the requirements tree can be harvested.
The UP--the most popular software engineering process in use today--is a useful first step in building your own development process. But it's not all Gouda. Here's a closer look at the good and not-so-good aspects of this application appetizer.
How good were my predictions for 2002? Let's run the numbers.
The guys who built the Empire State Building didn't just order a bunch of steel and start welding. There is real planning and design that has to go into really big projects, and here's one case where EAI is happening on a colossal scale.
Component-based development (CBD) approaches have been evolving over the last three to five years, but they have met with limited success. That is about to change. Building successful component-based software implies a few critical success factors.
A look at the past can be a good start at predicting the future. Here's what I see for the coming year...
For diplomats, teachers, journalists and travel agents, language is crucial to getting the job done. The same holds true for agents. If agents can't understand each other, how can they possibly work together? Here is further discussion from Jim Odell on the language of agents and its importance to systems development.
The next generation of Internet systems may need more than just DAD to succeed. Fortunately, MOM can help.
A new day is dawning in the world of distributed computing, and it's going to revolve around J2EE and EJBs. If you aren't up on these acronyms, wake up and smell the Java.
A look back at the past year and what it meant in terms of technology and systems architecture.
Sometimes the old ways are the best ways, and one of the oldest ways to communicate information about system design and implementation is the data flow diagram. Straightforward and simple to understand, this tool can be helpful in gathering requirements from non-technical users. Here’s an introduction for the uninitiated.
Headed for trouble? Here are some ways out of the mess. This article will revisit seven of the most common causes for project failure, consider their solutions and provide some techniques you might have missed such as developing an ERD from Day One, and driving the user interface based on the structure of your data.
Many organizations are pushing the envelope looking for ways to shorten their development cycle and improve their operational efficiency. An enterprise architecture program is the means to do that.
When the Agile movement becomes dogmatic, we’re left with the opposite of its original intent. The “purity” of any method should never rise above the purpose of a project, which always comes down to translating needs and delivering results. A combination of approaches seems to work best in reality — that is, more mish-mash, less manifesto.
