Object Oriented Software Engineering   View all facts   Glossary   Help

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

software engineer
subject			fact

software engineer	applies well-understood techniques in an organized and disciplined way
	assists the manager of the development team
	can design highly maintainable software by anticipating future changes and adding flexibility
	can write detailed requirements before starting to design the system only if he or she is developing software in a well-known domain and using well-known technology
	cannot develop a perfect user interface without the input of users
	cannot know whether a system meets the customer's needs until it is delivered and in use
	checks for 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
	communicates with other software engineers orally and in writing
	has definition A person who has education in, and experience performing software engineering; an engineer who specializes in software
	designs software systems
	does not have to become an expert in the domain to do domain analysis
	does not need to exceed quality objectives which helps them avoid spending more effort than is necessary
	fills in certain missing details of a framework to complete the application or subsystem it represents
	has purpose to solve problems economically by developing high quality software
	is a subtopic of 1.1 - The Nature of Software
	is often not educated as an engineer
	is rarely taught interviewing skills
	is a kind of engineer
	is a kind of software developer
	makes design decision by using all the knowledge at his or her disposal, including: Knowledge of the requirements Knowledge of the design as created so far Knowledge of the technology available Knowledge of software design principles and 'best practices' Knowledge about what has worked well in the past
	may become the manager of a development team at some point in her career
	may have to optimize 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
	may not reuse software because there are no reusable components available to reuse, or because they do not feel confident about reusing whatever is available
	may perform project management
	must be able to find reusable components
	must be able to write clear documentation
	must be understand the software architecture of a system they are working on
	must effectively communicate with people, to understand how they work and to understand what impact any proposed software may have on these people's productivity
	must ensure that his systems can be produced within a limited budget and by a certain due date
	must have sufficient general education, plus training in the technology to be used
	must plan 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
	must realize that 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
	performs domain analysis by gathering information from domain experts, books, software and its documentation, and any other available documents
	performs interviewing as part of requirements gathering
	performs observation as part of requirements gathering
	reuses commercial off-the-shelf software by adding extra code called glue code which is often written using scripting languages which run using an interpreter
	reuses complete applications and adapts them to the needs of the client by adding a small amount of extra software that makes the applications behave in special ways the client wants
	reuses expertise when they have many years of experience working on projects and can often save considerable time when it comes to developing new systems because they do not need to re-think many issues: their past experience tells them what needs to be done
	reuses frameworks
	reuses implemented algorithms, data structures and other facilities contained in libraries of classes or procedures, or of powerful commands built into languages and operating systems
	reuses standard designs and algorithms described in books, standards documents and articles by implementing them if they are appropriate to the current task
	should adjust the requirements or design as soon as important changes are discovered
	should avoid duplication of requirements so as to help ensure consistency
	should avoid obscure features of any technology
	should avoid requirements creep
	should avoid technology sold by just a single vendor and which has relatively few other customers
	should balance the benefits of the use of third-party technology with the risks of problems
	should be aware of things which may change
	should be able to use cost-benefit analysis to choose among alternatives
	should build flexibility and other aspects of maintainability into the software from the start so that changes are easier to make
	should check the consistency of requirements with any standards, with other requirements in the document, with higher-level requirements and with the requirements for other subsystems
	should combine the best features of each process model
	should continually interact with users and clients to keep up-to-date on their needs
	should create prototypes to try out the technology you will be using
	should design system to meet quality objectives
	should design user interface after doing some domain analysis and defining the problem
	should design for flexibility to accommodate potential changes
	should design with change in mind
	should develop negotiating and other 'people' skills
	should develop prototypes based on rough requirements to check out the validity of the ideas or the reliability of the technology before writing detailed requirements
	should divide a system into smaller subsystems, so that each one is naturally simpler
	should evaluate the requirements in a project where requirements have already been determined to ensure that the requirements on which is based are of good quality
	should follow a good requirements gathering and analysis process
	should follow the IEEE/ACM code of ethics
should have a mentor
should have user interface design skills
should learn how users and customers think and behave so it will be easier to produce software that meets their needs
should make their designs reusable by designing and documenting software so that it is understandable and flexible enough be used in a variety of different systems
should narrow the scope^2 of a system if possible by defining a more precise problem
should not accept a contract where she is required to implement requirements with no changes allowed
should not add unnecessary new features
should not ignore long-term needs of the customers
should not rush changes
should not undertake a serious software project without doing domain analysis
should participate in promoting and marketing the project
should perform quality assurance activities on each change in a system
should practice on prototypes or systems that are of lesser importance in order to gain sufficient experience in a particular technology
should prototype the system early, especially those parts that involve complex algorithms, in order to determine whether performance will be satisfactory
should recognize 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
should redesign parts of an over-complex system as necessary
should regularly evaluate how the system will impact all the stakeholders, and work closely with them to foster increased understanding of issues
should remove features that are not needed
should reuse others' work, rather than re-developing software that others have already developed
should set objectives for quality when starting a project
should study Peter G. Neumann's Risks Digest to ensure they do not recreate the failures listed in it
should take time to understand software before making changes
should understand process standards
should understand the application domain so he or she can communicate effectively with clients and users
should understand basically how their managers run projects
should use tools that aid in understanding the structure of a software system
should use widely used technology because it is more likely to be supported and have had its defects removed
should work with the customer to resolve any problems with requirements in a project where requirements have already been determined
uses use case analysis to help define the tasks that the user interface must help the user perform
engineer	did not have to be licensed before the 1940's in most jurisdictions
	has role to put knowledge to use in innovative ways to solve problems
	must adhere to a code of ethics
	must be licensed in most countries in order to legally perform consulting or self-employed work where you call yourself an 'engineer'
	must take personal responsibility for work
software developer	asks several evaluators to independently perform heuristic evaluations
	has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise
	is part of software development team
	maintains software
	may be judged on when they deliver product, not on its quality level
	may refuse to reuse components in which they lack confidence
	most often works on custom software
	must inform the project manager about any problems
	often fails to adequately involve users in the development process
	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 development
	should be rewarded for developing reusable components
	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 value
	should identify all the use cases associated with the software product
	should not document a design only after it is complete
	should not omit design documentation
	should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them
	should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence
	should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs
	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 software
	wants software that is easy to design and maintain and which has parts that are easy to reuse
stakeholder	must agree on requirements

Kinds of software engineer :

• software engineer doing interviewing (8 facts)

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