Object Oriented Software Engineering   View all facts   Glossary   Help

subject > person or group > person > stakeholder > software developer

software developer comparison table

Subject	learn from	restructure	fill in	recognize	choose	involve	accept	rush	adjust	have role	teach	adhere to	become	use	communicate with	learn	catalog	implement	check for	redesign	create	add	include	plan	build	be part of	check	reuse	practice on	ensure that	comment	measure	estimate	ensure	ignore	take personal responsibility for	work with	develop	revise	set	lead	license	optimize	perform	underestimate	remove	realize that	interact with	document	evaluate	understand basically	has definition	group	consider	participate in	be	design for	is a subtopic of	test	complete	prototype	monitor	exceed	narrow	know that	keep	reject	undertake	take advantage of	know	ask	refine	avoid	understand	stop	follow	need	violate	take time	balance	educate as	study	have purpose	divide	run	overcome	assist	write	make	have difficulty	provide	compare	pay attention to	remember	apply	design	combine	license in	have	find	design with
architect														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete			The person responsible for leading the decision-making about the architecture, and maintaining the architectural model						9.4 - Software Architecture													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
configuration management specialist														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete							responsible for ensuring that changes are made, no new problems are introduced and that documentation for each change is properly updated		1.4 - Stakeholders in Software Engineering													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
cost estimator														cost estimation principles									extra time into a time estimate to account for typical delays					technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously			time by making 3 separate estimates - optimistic, likely and pessimistic - to come up with a global estimates of the best-case, typical case and worst-case cost for the project					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	estimates because As you gather requirements and begin specifying details, you will be able to increase the accuracy of your estimate As you move into the design phase, you can again increase the accuracy of your estimates You will adjust your estimates as requirements change, or features are dropped in order to meet a budget or deadline As you encounter problems during design and implementation, you will be able to adjust your estimates to take these into account					cost estimation	the total amount of work required by not understanding the amount of work involved in certain activities or omitting them entirely				a design only after it is complete					differences when making an estimate for a new project: different software developers with different skill levels different development processes and maturity levels different types of customers and users different schedule demands different technology different technical complexity of the requirements Different domains Different levels of requirement stability				11.3 - Cost Estimation													several evaluators to independently perform heuristic evaluations		making only a best-case estimate	the customer's business environment, their problems and the available technology which can be used to solve the problems										the project up into individual subsystems, and then divide each subsystem further into the activities that will be required to develop it, then make a series of detailed estimates for each individual activity, and sum the results to arrive at the grand total estimate for the project					inaccurate estimate if he or she tries to estimate the entire cost of a project as a single number			the results of several different cost estimation techniques							significantly less knowledge about modelling than about design and programming
database specialist														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete									1.4 - Stakeholders in Software Engineering													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
design pattern developer														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete									6.15 - Using Design Patterns - References													several evaluators to independently perform heuristic evaluations	patterns iteratively and have then peer reviewed at each iteration	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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems														patterns for others to use until he or she has considerable experience both in software design and in the use of patterns											significantly less knowledge about modelling than about design and programming
designer	studying patterns													cost-benefit analysis to choose among alternatives							skeletons for the files that will contain the code							technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete							a programmer		1.7 - Activities Common to Software Projects													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems								designs of other systems, including designs that have been found to be bad							design decision							large systems until she has experienced a wide variety of software development projects			significantly less knowledge about modelling than about design and programming	ways to reduce costs and increase benefits
distributed system developer														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								harmful programs such as viruses or Trojan horses or hack into systems						cost estimation	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 development				a design only after it is complete									3.11 - Basing Software Development on Reusable Technology - References													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems				the privacy of users by gathering data about people as they use network-based programs or by actively intercepting communications unless users have consented to the release of their private information																					significantly less knowledge about modelling than about design and programming
evaluator														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						heuristic evaluation to test usability	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 development				a design only after it is complete									7.6 - Evaluating User Interfaces													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
framework developer														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces				design elements that are common to several applications										technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously				that the framework is well tested and reviewed				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						cost estimation	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 development				a design only after it is complete									3.3 - Frameworks: Reusable Subsystems													several evaluators to independently perform heuristic evaluations		divergent changes by designing the framework to be general enough	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
hardware and third-party software specialist														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces												software development team		technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete							responsible for making sure that the development team has appropriate types of hardware and third-party software on which to develop and test the software installing and performing acceptance testing on any reusable components the team plans to use		11.4 - Building Software Engineering Teams													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
mentor														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete									1.9 - Difficulties And Risks In Software Engineering as a Whole													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
modeller														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						modelling	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 development				a design only after it is complete									5.10 - Difficulties and Risks When Creating Class Diagrams													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
programmer		code to make it simpler if necessary			alternative that makes code simpler over more complicated one							object oriented principles		consistent code layout style		documentation navigation, which includes looking up the methods available to achieve some objective					several small classes, rather than one big, complex class							technology that others are also reusing		the code she writes based on a UML diagram always respects the constraints imposed by each OCL statement	obvious things since they add clutter			that anything that is true in a superclass is also true in its subclasses				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						cost estimation	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 development				a design only after it is complete				classes into logical sections with a clear comment separating each section if a class has many methods			responsible for anticipating things that can go wrong and writing exception handling code in preparation		Programming Style Guidelines								the number of instance variables small. If this number exceeds 10, then consider splitting the class into separate classes - e.g. a superclass and a subclass	'clever' or 'cool' coding techniques unless they make the code simpler to understand		polymorphism, inheritance, abstract classes, and methods		several evaluators to independently perform heuristic evaluations		over-use of class variables or class methods	the customer's business environment, their problems and the available technology which can be used to solve the problems		consistent guidelines that make programs easy to read when writing programs												program		thinking at the level of abstraction needed to create effective models			to the documentation describing which features of Java are deprecated	that shorter code is not necessarily better code but unnecessarily long code is also bad	the 'isa' rule religiously	the system			significantly less knowledge about modelling than about design and programming
requirements specialist														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete									1.4 - Stakeholders in Software Engineering													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
reusable component developer														a catalog of reusable components to find appropriate components			reusable components so that software engineers will be able to find them							the development of the reusable technology, in the same manner as if it were a product for a client	confidence in the reusable technology by guaranteeing support ensuring it is of high quality responding to the needs of the users			technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								software components that are intended to be reused						cost estimation	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 development				reusable components so that software engineers will be able to use them easily									3.2 - Incorporating Reusability and Reuse Into Software Engineering				the success or failure of the reusable software so you can improve your investment decisions in future projects									several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems		the same steps as the development of complete applications: domain and requirements analysis, design, documentation, testing and inspection										competition with other developers of reusable components by: Ensuring the reusable technology is as useful and as high quality as possible Advertise the presence and advantages of the reusable software					support for the components after they are developed								significantly less knowledge about modelling than about design and programming
software architect														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces												software development team		technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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			a team of software engineers			cost estimation	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 development				a design only after it is complete							responsible for leading the decision-making about the architecture, and maintaining the documentation describing the architectural model		9.4 - Software Architecture													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
software developer practising user centred design						users in the decision making process as much as possible throughout development								a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								an understanding of the users of a system						use case analysis	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 development				a design only after it is complete									7.1 - User Centred Design												the characteristics of her users allows her to design a system that matches their level of knowledge, their abilities and their preferences	users to work with and give their feedback about prototypes, on-line help and draft user manuals		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																						the user interface following principles of good usability			significantly less knowledge about modelling than about design and programming
software developer using a framework			hooks and slots											services that the framework provides, i.e. methods that perform useful functions, called the API														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete									3.3 - Frameworks: Reusable Subsystems													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
software engineer			certain missing details of a framework to complete the application or subsystem it represents	activities that are not consistent with the goal of solving customers' problems, such as adding unnecessary features, and situations when it would be most cost effective not to develop software at all, to develop simpler software or to purchase existing software			a contract where she is required to implement requirements with no changes allowed	changes	the requirements or design as soon as important changes are discovered	to put knowledge to use in innovative ways to solve problems	interviewing skills	a code of ethics	the manager of a development team at some point in her career	use case analysis to help define the tasks that the user interface must help the user perform	people, to understand how they work and to understand what impact any proposed software may have on these people's productivity	how users and customers think and behave so it will be easier to produce software that meets their needs			valid generalizations by checking that: superclasses and subclasses have unambiguous names each subclass retains its distinctiveness throughout its life all the inherited features make sense in each subclass	parts of an over-complex system as necessary	prototypes to try out the technology you will be using	unnecessary new features		budget and schedule which requires a great deal of knowledge about what is required to produce a system, and how long each activity should take	flexibility and other aspects of maintainability into the software from the start so that changes are easier to make		the consistency of requirements with any standards, with other requirements in the document, with higher-level requirements and with the requirements for other subsystems	others' work, rather than re-developing software that others have already developed	prototypes or systems that are of lesser importance in order to gain sufficient experience in a particular technology	his systems can be produced within a limited budget and by a certain due date					long-term needs of the customers	work	the customer to resolve any problems with requirements in a project where requirements have already been determined	prototypes based on rough requirements to check out the validity of the ideas or the reliability of the technology before writing detailed requirements		objectives for quality when starting a project		before the 1940's in most jurisdictions	certain aspects of designs - achieving the best possible levels of certain qualities, while not exceeding a certain budget and at the same time meeting objectives for the other qualities	quality assurance activities on each change in a system	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 development	features that are not needed	the vicious circle of software reuse exists and costs money - in order to save money in the longer term, an investment in reusable code is justified	users and clients to keep up-to-date on their needs	a design only after it is complete	how the system will impact all the stakeholders, and work closely with them to foster increased understanding of issues	how their managers run projects	A person who has education in, and experience performing software engineering; an engineer who specializes in software			promoting and marketing the project	aware of things which may change	flexibility to accommodate potential changes	1.1 - The Nature of Software			the system early, especially those parts that involve complex algorithms, in order to determine whether performance will be satisfactory		quality objectives which helps them avoid spending more effort than is necessary	the scope^2 of a system if possible by defining a more precise problem				a serious software project without doing domain analysis		whether a system meets the customer's needs until it is delivered and in use	several evaluators to independently perform heuristic evaluations		technology sold by just a single vendor and which has relatively few other customers	the application domain so he or she can communicate effectively with clients and users		the IEEE/ACM code of ethics			to understand software before making changes	the benefits of the use of third-party technology with the risks of problems	an engineer	Peter G. Neumann's Risks Digest to ensure they do not recreate the failures listed in it	to solve problems economically by developing high quality software	a system into smaller subsystems, so that each one is naturally simpler			the manager of the development team	clear documentation	their designs reusable by designing and documenting software so that it is understandable and flexible enough be used in a variety of different systems						well-understood techniques in an organized and disciplined way	user interface after doing some domain analysis and defining the problem	the best features of each process model	most countries in order to legally perform consulting or self-employed work where you call yourself an 'engineer'	user interface design skills	reusable components	change in mind
technical writer														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces														technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete							responsible for ensuring that on-line help and user manuals are well written		1.4 - Stakeholders in Software Engineering													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
technology specialist														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces												software development team		technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously								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						cost estimation	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 development				a design only after it is complete							responsible for specialized knowledge and expertise in a technology such as databases, networking, operating systems etc.		11.4 - Building Software Engineering Teams													several evaluators to independently perform heuristic evaluations		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 market	the customer's business environment, their problems and the available technology which can be used to solve the problems																									significantly less knowledge about modelling than about design and programming
tester														a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces												software development team		technology that others are also reusing		the set of use cases is complete and that they are expressed consistently and unambiguously		the quality of both the product and the process which This allows you to plot the quality over a period of time and determine whether it is improving or not						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						cost estimation	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 development				a design only after it is complete							suspicious		10.2 - Effective and Efficient Testing	every equivalence class of every individual input all combinations where an input is likely to affect the interpretation of another values at the boundaries of equivalence classes	basic testing before inspecting software					software developers tend to have certain habits that can lead to errors, and hence to defects						several evaluators to independently perform heuristic evaluations		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 market	how programmers. designers and users think, so as to better find defects	testing just when money or time runs out - the result is low quality software that fails often when users start to use it		knowledge of software design to determine the equivalence classes of inputs								one test per equivalence class using a representative member of that equivalence class as input								detail			tests that explicitly try to catch a range of specific types of defects that commonly occur			significantly less knowledge about modelling than about design and programming	defects by anticipating typical errors made by developers anticipating unusual things that users might try to do

Next stakeholder: user    Up: stakeholder    Previous stakeholder: project manager