Design from Fred Brook’s Perspective
- System design is not artistic design.
- Function over form.
- Never sacrifice functionality for aesthetics.
Design is planning, implementation, and interaction.
- Implementation reveals design problems, interaction reveals implementation problems.
- “You need to do the next step to see what mistakes you made”.
- Often details don’t translate into implementation.
- Design models need to account for iteration, or else there will be no opportunity to correct oversights or mistakes.
- There are some areas and types of software that are better understood than others.
- Routine designs do exist for software.
- Original designs tend to be for new things.
- If you are going to do new things you will need to decide if the traditional design paradigms are still applicable.
Waterfall Model (winston Royce)
- System Requirements
- Software Requirements
- System Design
- Better than nothing.
- Introduced clear steps which where clearly defined.
- Identified different roles and positions required for software development.
- Assumes that you know what the core problem or issue that needs to be addressed.
- Designers don’t operate well using this ridged series of steps.
- Didn’t take into account iteration.
Design By Committee
- If nobody is in charge than there is no accountability, requirement or responsibility.
- Results in a wish list, or unrealistic list of requirements
- Requirements Bloat: when you have made too many requirements introduced initially
- Requirements Creep: when unnecessary requirements are added mid-development and divert focus
- Software is typically developed in teams, especially at a commercial level.
- Commercial software is becoming more complicated, and it requires niche expertise.
- Telecommunications is becoming a more prevalent element of development.
- In the 19th and 20th century, most large tech breakthroughs where the product of one or two individuals.
- Teams are more common and require different management styles and result in a loss of conceptual integrity (focus).
- Teams are useful to make software quicker; that being said, adding more people to a late project does not ship it out faster.
- Software development is often difficult to partition and integrate; there often aren’t clear boundaries between elements of a program.
- Adding team members increases the number of paths of communication exponentially.
- Ultimately collaboration is important because it shortest the time for completion.
- Different stakeholders will have a different perspective on design and different concerns.
- ie. sales, marketing, client, developer, etc.
Software Tools For Collaboration
- svn, subversion
- redmine (project management)