August 9, 2007
Designing Solutions That Fit – Proven Methods for Common Scenarios
Dan Massey, Partner and Chief Architect, Capability Measurement
Designing systems and software requires skill and care with a variety of tools and techniques. The industry has many approaches from which to choose, yet each individual has their own favorites which they hone and adapt to the situations they face. Unless they can see how someone else leverages a different method or tool, designers are likely to continue doing what they’ve found useful in the past – even if it means chiseling Booch diagrams onto stone tablets.
In this month’s presentation, our speaker examines the realm of software design, considering five key questions. In addition, he considers how to approach some common scenarios for design, discussing which methods and tools fit best – and inviting audience reactions and alternatives for which they have had success in these scenarios. For details, see below.
Then, the audience will be asked to pose some scenarios for discussion in which they have either:
had problems and want to explore alternatives
consistently been successful with their favorite design approach
or found a novel way to approach a design problem
About the Speaker:
Our speaker is Dan Massey, a Partner at Capability Measurement where he serves as Chief Architect. Capability Measurement delivers organizational insight by adding continuous human feedback to change management projects and business intelligence tools. Previously he was ALM Product Manager, Functional Architect, and Chief Technical Architect at Borland Software Corporation. In these roles, Massey’s main focus was advancing Borland's Open ALM vision. His work on Open ALM included ALM data integration strategies, Borland's software process enactment metamodel, and the functional architecture for integrated Open ALM. Prior to joining Borland, Dan was a TogetherSoft Mentor and Java EE architect. As a TogetherSoft Mentor, Massey worked with architects and development teams of TogetherSoft customers to design and document applications in many domains and varied shapes and sizes.
Details (Dan Massey, ASPIN, August 2007):
Questions the speaker will address:
Where do you typically start when approaching design for a new project?
Architectural design versus component or low-level design?
Where do business processes fit?
When using different processes? Agile? UP?
What tools and techniques do you use for design validation and verification?
What techniques do you use for design reviews when the team members are geographically dispersed?
What methods and tools do you use to perform traceability back to requirements and forward to the code and test cases?
How do you communicate design ideas and issues to stakeholders?
Scenarios the speaker will consider
Scenarios the speaker will consider:
You’re part of a maintenance team working with a 10-year-old mainframe system implemented in COBOL. There’s not much design documentation other than what’s in the comments in the code. You know about the previous requirements and changes to the system from a collection of Change Requests (CR’s). You now need to add a major feature to this system. What do you do?
You have been assigned to a project to project developing a new set of SOA applications for a well funded startup. The company and team are committed to agile development.
Your team has been asked to provide a web front end to an existing mainframe banking application, so that users can review their bank balances, establish automatic bill payment, and shift money between their own accounts (e.g. savings and checking). How do you approach the design?