Object Oriented Software Engineering   View all facts   Glossary   Help

subject > person or group > person > engineer > software engineer

software engineer comparison table

Subject	fill in	recognize	accept	adjust	rush	have role	teach	adhere to	become	use	communicate with	learn	check for	hold	redesign	create	add	plan	build	check	reuse	practice on	work for	ensure that	ignore	realize	work with	take personal responsibility for	develop	set	license	optimize	is a kind of	perform	underestimate	remove	realize that	interact with	document	evaluate	is part of	understand basically	emphasize	allow	participate in	fail to	refuse	be	have goal	design for	is a subtopic of	want	prototype	exceed	maintain	narrow	prepare	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	interview	assist	write	make	apply	design	combine	have	license in	find	design with
software engineer doing interviewing	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	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	a series of interviews with the most important stakeholders	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	work	listening skills and empathy for users and customers	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	software engineer	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	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	several hours for each interview	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	4.6 - Some Techniques for Gathering and Analyzing Requirements	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	an extensive list of questions	a serious software project without doing domain analysis	whether a system meets the customer's needs until it is delivered and in use	requirements	about specific details such as maximums and minimums, whether there are any exceptions to rules and what possible changes might be anticipated about the stakeholder's vision for the future about any alternative ideas, or how they would feel about alternative ideas you have what would be a minimally acceptable solution to the problem about other sources of information the interviewee to draw diagrams or such things as the flow of information, the chain of command or how some technology works	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	as many stakeholders as possible, as well as users of competing products, marketing personnel, and people involved with other systems that may interact in any way with the proposed system	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	most countries in order to legally perform consulting or self-employed work where you call yourself an 'engineer'	reusable components	change in mind

Next engineer: Chartered Engineer    Up: engineer, software developer    Previous engineer: professional engineer