engineer Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

subject > person or group > person > engineer

Next person: moderator Up: person Previous person: domain expert

engineer comparison table

Subject fill in recognize accept adjust rush teach become use communicate with learn check for redesign create add plan build check reuse practice on work for ensure that ignore realize work with develop set optimize is a kind of perform underestimate remove realize that interact with document evaluate is part of understand basically has definition emphasize participate in fail to refuse be have goal design for is a subtopic of want prototype exceed maintain narrow undertake know agree on ask inform avoid understand follow identify take time work on balance study educate as have purpose omit divide reward for judge on assist write make apply design combine have find design with

Chartered Engineer established designs engineer A term used in the United Kingdom, and certain other jurisdictions, that is equivalent to professional engineer 1.3 - Software Engineering as a Branch of the Engineering Profession that omitting design documentation or documenting a design after it is complete is unacceptable, leads to serious mistakes, and makes planning for construction impossible well-understood principles artefacts following well accepted practices which normally involve the application of science, mathematics and economics sufficient engineering education and experience to be licensed

professional engineer established designs engineer A person who has been issued a license, by some jurisdiction, to perform engineering 1.3 - Software Engineering as a Branch of the Engineering Profession that omitting design documentation or documenting a design after it is complete is unacceptable, leads to serious mistakes, and makes planning for construction impossible well-understood principles artefacts following well accepted practices which normally involve the application of science, mathematics and economics sufficient engineering education and experience to be licensed

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 the requirements or design as soon as important changes are discovered changes interviewing skills 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 several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software his systems can be produced within a limited budget and by a certain due date long-term needs of the customers that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs 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 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 software developer 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 software development team how their managers run projects A person who has education in, and experience performing software engineering; an engineer who specializes in software 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 value promoting and marketing the project adequately involve users in the development process to reuse components in which they lack confidence aware of things which may change rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise flexibility to accommodate potential changes 1.1 - The Nature of Software software that is easy to design and maintain and which has parts that are easy to reuse 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 software 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 requirements several evaluators to independently perform heuristic evaluations the project manager about any problems 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 all the use cases associated with the software product to understand software before making changes custom software the benefits of the use of third-party technology with the risks of problems Peter G. Neumann's Risks Digest to ensure they do not recreate the failures listed in it an engineer to solve problems economically by developing high quality software design documentation a system into smaller subsystems, so that each one is naturally simpler developing reusable components when they deliver product, not on its quality level 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 user interface design skills reusable components change in mind

Next person: moderator Up: person Previous person: domain expert

Subject	fill in	recognize	accept	adjust	rush	teach	become	use	communicate with	learn	check for	redesign	create	add	plan	build	check	reuse	practice on	work for	ensure that	ignore	realize	work with	develop	set	optimize	is a kind of	perform	underestimate	remove	realize that	interact with	document	evaluate	is part of	understand basically	has definition	emphasize	participate in	fail to	refuse	be	have goal	design for	is a subtopic of	want	prototype	exceed	maintain	narrow	undertake	know	agree on	ask	inform	avoid	understand	follow	identify	take time	work on	balance	study	educate as	have purpose	omit	divide	reward for	judge on	assist	write	make	apply	design	combine	have	find	design with
Chartered Engineer																		established designs										engineer										A term used in the United Kingdom, and certain other jurisdictions, that is equivalent to professional engineer								1.3 - Software Engineering as a Branch of the Engineering Profession												that omitting design documentation or documenting a design after it is complete is unacceptable, leads to serious mistakes, and makes planning for construction impossible																well-understood principles	artefacts following well accepted practices which normally involve the application of science, mathematics and economics		sufficient engineering education and experience to be licensed
professional engineer																		established designs										engineer										A person who has been issued a license, by some jurisdiction, to perform engineering								1.3 - Software Engineering as a Branch of the Engineering Profession												that omitting design documentation or documenting a design after it is complete is unacceptable, leads to serious mistakes, and makes planning for construction impossible																well-understood principles	artefacts following well accepted practices which normally involve the application of science, mathematics and economics		sufficient engineering education and experience to be licensed
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	the requirements or design as soon as important changes are discovered	changes	interviewing skills	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	several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software	his systems can be produced within a limited budget and by a certain due date	long-term needs of the customers	that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs	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	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	software developer	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	software development team	how their managers run projects	A person who has education in, and experience performing software engineering; an engineer who specializes in software	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 value	promoting and marketing the project	adequately involve users in the development process	to reuse components in which they lack confidence	aware of things which may change	rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise	flexibility to accommodate potential changes	1.1 - The Nature of Software	software that is easy to design and maintain and which has parts that are easy to reuse	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	software	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	requirements	several evaluators to independently perform heuristic evaluations	the project manager about any problems	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	all the use cases associated with the software product	to understand software before making changes	custom software	the benefits of the use of third-party technology with the risks of problems	Peter G. Neumann's Risks Digest to ensure they do not recreate the failures listed in it	an engineer	to solve problems economically by developing high quality software	design documentation	a system into smaller subsystems, so that each one is naturally simpler	developing reusable components	when they deliver product, not on its quality level	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	user interface design skills	reusable components	change in mind