Object Oriented Software Engineering   View all facts   Glossary   Help
subject > person or group > person > stakeholder > software developer > designer > software designer
Next designerUML diagram designer    Updesigner    Previous designeruser interface designer   

software designer
subjectfact 
software designeris a subtopic of 9.1 - The Process of Design2001-08-30 14:57:35.0
is a kind of designer2001-08-30 14:57:35.0
may have to propose that the requirements be changed if new issues raised by design decisions have no solutions2001-08-30 14:57:35.0
may have to revise previous decisions if new issues raised by design decisions have no solutions2001-08-30 14:57:35.0
may not propose the same solution to a design issue as another designer2001-08-30 14:57:35.0
should explore different paths through design space - investigating the consequences of choosing different alternatives when major issues arise2001-08-30 14:57:35.0
designercan create skeletons for the files that will contain the code2001-08-30 14:55:17.0
can learn from studying patterns2001-08-30 14:55:17.0
can use cost-benefit analysis to choose among alternatives2001-08-30 14:55:17.0
makes design decision2001-08-30 14:55:17.0
may also be a programmer2001-08-30 14:55:17.0
must find ways to reduce costs and increase benefits2001-08-30 14:55:17.0
should not design large systems until she has experienced a wide variety of software development projects2001-08-30 14:55:17.0
should study designs of other systems, including designs that have been found to be bad2001-08-30 14:55:17.0
software developerasks several evaluators to independently perform heuristic evaluations2001-08-30 14:57:35.0
can avoid creating design documents before starting to program but this is not a good idea and tends to result in an inflexible and overly-complex system2001-08-30 14:57:35.0
develops software2001-08-30 14:57:35.0
has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise2001-08-30 14:57:35.0
is part of software development team2001-08-30 14:57:35.0
maintains software2001-08-30 14:57:35.0
may be judged on when they deliver product, not on its quality level2001-08-30 14:57:35.0
may be reluctant to develop new libraries, APIs and frameworks because
  • developing anything reusable is seen as not directly benefiting the current customer
  • If a developer has painstakingly developed a high-quality reusable component, but management only rewards the efforts of people who create the more visible 'final product', then that developer will be reluctant to spend time on reusable components in the future
  • Efforts at creating reusable software are often done in a hurry and without enough attention to quality. People thus lose confidence in the resulting components, and in the concepts of reuse and reusability
2001-08-30 14:57:35.0
may refuse to reuse components in which they lack confidence2001-08-30 14:57:35.0
most often works on custom software2001-08-30 14:57:35.0
must ensure that the set of use cases is complete and that they are expressed consistently and unambiguously2001-08-30 14:57:35.0
must inform the project manager about any problems2001-08-30 14:57:35.0
must understand the customer's business environment, their problems and the available technology which can be used to solve the problems2001-08-30 14:57:35.0
often fails to adequately involve users in the development process2001-08-30 14:57:35.0
often has significantly less knowledge about modelling than about design and programming2001-08-30 14:57:35.0
often underestimates software development time because it is very hard for people to assess the quality of software or to appreciate the amount of work involved in its development2001-08-30 14:57:35.0
performs cost estimation2001-08-30 14:57:35.0
reuses libraries and APIs delivered with a programming language2001-08-30 14:57:35.0
should avoid the use of obscure features of technology because later versions of the technology might be changed in ways that are incompatible with how you have used it or the producer of the technology might go out of business or withdraw it from the market2001-08-30 14:57:35.0
should be rewarded for developing reusable components2001-08-30 14:57:35.0
should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value2001-08-30 14:57:35.0
should identify all the use cases associated with the software product2001-08-30 14:57:35.0
should not document a design only after it is complete2001-08-30 14:57:35.0
should not omit design documentation2001-08-30 14:57:35.0
should only reuse technology that others are also reusing2001-08-30 14:57:35.0
should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them2001-08-30 14:57:35.0
should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence2001-08-30 14:57:35.0
should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs2001-08-30 14:57:35.0
should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software2001-08-30 14:57:36.0
wants software that is easy to design and maintain and which has parts that are easy to reuse2001-08-30 14:57:36.0
stakeholdermust agree on requirements2001-08-30 14:57:46.0

Next designerUML diagram designer    Updesigner    Previous designeruser interface designer