Software Engineering Fundamentals

Chapter I

• Software differs from other engineering artifacts as both a product and a vehicle for delivering a product

• As a product, software transforms information

• As a delivery vehicle, it serves as a basis for computer control, communication, and creation

• Software is developed, not manufactured

• Software does not wear out over time

• Software is custom built, not assembled from components

• Computer software evolves as errors are discovered and corrected

• Software adapts to changes in the computing environment

• Customers request changes to add new functions or accommodate business needs

• Re-engineering may be needed to provide benefits in a modern context

• Software that does not evolve eventually becomes unusable

• Process models differ in overall flow and level of task interdependencies

• Process models differ in the degree to which work tasks are defined within each framework

• Process models differ in the degree to which work products are identified and required

• Process models differ in terms of manner in which quality assurance and project tracking activities are applied

• Process models differ in the overall degree of detail and rigor of process description

• Process models differ in the degree to which stakeholders are involved in the project

• Process models differ in the level of autonomy given to the project team

• Process models differ in how team organization and roles are prescribed

• Polya's problem-solving principles are applicable to engineering practice

• Understanding the problem involves communication and analysis

• Planning a solution involves modeling and design

• Carrying out the plan involves code generation

• Examining the result involves testing and quality assurance

Chapter II

• The software team chooses the task set based on the characteristics of the team, the project, and the problem being addressed

• Process patterns assist by providing proven solutions to common development problems

• Developers can use them if they recognize a previously seen problem

• Prevents the need to invent a new solution

• Agile software processes provide stability, control, and organization to prevent chaos

• Modern software processes demand appropriate activities, controls, and work products for the team and product

• This ensures accommodation of changes and high-quality product delivery

• Phases of the prototyping model involve gathering requirements by having the customer and developer meet

• A quick design follows, focusing on representation of the software visible to the customer

• A prototype is built by the developer, evaluated by the customer, and used to refine requirements

• Iteration occurs, and the prototype is tuned to satisfy customer needs

• Evolutionary models are considered optimal for modern software development

• Timelines are getting shorter, customers are more diverse, and requirements change frequently

• Evolutionary processes accommodate uncertainty and partial solutions

• Evolutionary processes reflect how complex systems are built

Chapter III

• Agile philosophy stresses self-organizing teams

• Agile philosophy stresses communication and collaboration between team members and customers

• Agile philosophy stresses on recognition that change represents opportunity

• Agile philosophy stresses on rapid delivery of software that satisfies the customer

• Agile "Manifesto" values individuals and interactions over processes and tools

• Agile "Manifesto" values working software over comprehensive documentation

• Agile "Manifesto" values customer collaboration over contract negotiation

• Agile "Manifesto" values responding to change over following a plan

• Customers and end-users are full collaborators on agile process teams

• They provide information for use cases and business value of software features

• They give feedback on operational prototypes during incremental software development

• Agile processes must address the unpredictability of software requirements and customer priorities

• Agile processes must address the interleaving of design and construction

• Agile processes must address the unpredictable nature of analysis, design, construction, and testing

• At a daily Scrum meeting; team members answer what have you done since the last meeting

• At a daily Scrum meeting; team members answer what obstacles are you encountering

• At a daily Scrum meeting; team members answer what do you plan to accomplish by the next meeting

Chapter IV

• Requirements engineering should be iterative because stakeholders cannot fully describe a system before seeing it work

• Stakeholders struggle to define quality requirements without a prototype

• Developers must recognize that requirements evolve as software increments are created

• Prototypes increase requirement volatility if stakeholders are not focused on getting things right initially

• Software decision-making is critical because system architecture determines qualities and impacts the system life cycle

• Architects make errors when making decisions with uncertainty

• Architects reduce bad decisions through better architectural knowledge management

• Lessons learned from retrospectives should be documented, conducted after prototype evaluation, and before next program increment

• Prototypes should be created with deployment in mind to avoid shortcuts that lead to unmaintainable software

• Careful consideration should be given to software architectural choices

• Changing application architecture is expensive once it is released to end-users globally

• It is important to test a prototype using stakeholders to reduce the risk of developing the wrong product

• Development team members are not representative of all users

• The right mix of users (novice, typical, and advanced) gives meaningful feedback

• Four types of maintenance: corrective, adaptive, preventative, and perfective

• Adaptive maintenance changes to adapt to a new working environment

• Preventative maintenance prevents future failures

• Perfective maintenance improves the product

Chapter V

• Software engineers should possess a sense of individual responsibility

• Software engineers should possess an acute awareness of the needs of other team members

• Software engineers should possess: brutal honesty, resilience under pressure, heightened under pressure, and attention to detail

• Software engineers should take a pragmatic approach to software engineering

• Attributes of an effective software team: a sense of purpose, involvement, trust, and improvement

• Effective software teams have diversity of team member skill sets

• Toxic environment characteristics: frenzied work atmosphere, high frustration causing friction, fragmented or poorly coordinated process

• Other toxic environment characteristics: unclear definition of roles, continuous exposure to failure, and differing team member traits

• Agile philosophy avoids team toxicity by encouraging customer satisfaction and early incremental delivery

• Agile philosophy prioritizes small, motivated teams, informal methods, minimal products, and simplicity

• Global teams decision making is complicated by complexity, uncertainty, risk, and unintended consequences

• Global teams decision making is complicated by views of the problem that can lead to forward conclusions

Chapter VI

• The main goal of software engineering is to deliver high-quality software on time with functions and features meeting all stakeholder needs

• A customer is often the person requesting a software product, while an end-user is who will manage it

• Representations needed for requirements and design models include;

• Requirements model should include information, functional, and behavioral aspects

• Design model should include architecture and user interface

• Key elements of construction activity involve coding and testing leading to software delivery

• Coding involves selecting languages, tools, standards, and environments

• Testing involves validating components and integrating them by stakeholders

• Software construction involves coding and testing a software increment

• Software deployment involves delivering an operational product, supporting it, and processing user feedback