Skip to content

Notes & Essentials of Software Engineering: A Practitioner's Approach 8th edition

Notifications You must be signed in to change notification settings

thunderrun/software-engineering-cheat-sheet

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

29 Commits
 
 

Repository files navigation

Software Engineering A Practitioner's Approach

The Process Framework

  • Communication
  • Planning
    • estimation
    • scheduling
    • risk analysis
  • Modeling
    • analysis
    • design
  • Construction
    • code
    • test
  • Deployment
    • delivery
    • feedback

Umbrella Activities

  • Software project tracking and control
  • Risk management
  • Software quality assurance
  • Technical reviews
  • Measurement
  • Software configuration management
  • Reusability management
  • Work product preparation an production

The Essence of Practice

  • Understand the problem
  • Plan the solution
  • Carry out the plan
  • Examine the result

General Principles

  • The reason it all exists
  • Keep it simple, stupid!
  • Maintain the vision
  • What you produce, other will consume
  • Be open to the future
  • Plan ahead for reuse
  • Think!

Personal Software Process

  • Planning
  • High-level design
  • High-level design review
  • Development
  • Postmortem

Agility Principles

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Industrial Extreme Programming

  • Readiness assessment
  • Project community
  • Project chartering
  • Test-driven management
  • Retrospectives
  • Continuous learning

Characteristics of a Software Engineer

  • sense of individual responsibility
  • acute awareness
  • brutally honest
  • resilience under pressure
  • heightened sense of fairness
  • attention to detail

Principles That Guide Process

  • Be agile
  • Focus on quality at every step
  • Be ready to adapt
  • Build an effective team
  • Establish mechanisms of communication and coordination
  • Manage change
  • Assess risk
  • Create work products that provide value for others

Principles That Guide Practice

  • Divide and conquer
  • Understand the use of abstraction
  • Strive for consistency
  • Focus on the transfer of information
  • Build software that exhibits effective modularity
  • Look for patterns
  • When possible, represent the problem and its solution from a number of different
  • Remember that someone will mantain the software

Communication Principles

  • Listen
  • Prepare before you communicate
  • Someone should facilitate the activity
  • Face-to-face communication is best
  • Take notes and document desicions
  • Strive for collaboration
  • Stay focused; modularize your discussion
  • If something is unclear, draw a picture
  • Move on when
    • Once you agree to someone
    • If you can't agree to something
    • If a feature or function is unclear and cannot be clarified at the moment
  • Negotitation is not a contest or a game. It works best when both parties win.

Planning Principles

  • Understand the scope of the project
  • Involve stakeholders in the planning activity
  • Recognize that planning is iterative
  • Estimate based on what you know
  • Consider risk as you define the plan
  • Be realistic
  • Adjust granularity as you define the plan
  • Define how you intend to ensure quality
  • Describe how you intend to accommodate change
  • Track the plan frequently and make adjustments as required

Modeling Principles

  • The primary goal of the software team is to build software, not create models
  • Traval light--don't create more models than you need
  • Strive to produce the simplest model that will describe the problem or the software
  • Build models in a way that makes them amenable to change
  • Be able to state an explicit purpose for each model that is created
  • Adapt the models you develop to the system at hand
  • Try to build useful models, but forgot about building perfect models
  • Don't become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary
  • If you instincts tell you a model isn't right even though it seems okay on paper, you peobably have reason to be concerned
  • Get feedback as soon as you can

Requirements Modeling Principles

  • The information domain of a problem must be represented and understood
  • The functions that the software performs must be defined
  • The behavior of the software(as a consequence of external events)must be represented
  • The models that depict information, function, and behavior must be partitioned in a manner that uncover detail in a payered(or hierarchical) fashion
  • The analysis task should move from essential information toward implementation detail

Design Modeling Principles

  • Design should be traceable to the requirements model
  • Always consider the architecture of the system to be built
  • Design of data is as important as design of processing functions
  • Interfaces(both internal and external)must be designed with care
  • User interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use
  • Component-level design should be functionally independent
  • Components should be loosely coupled to one another and to the external environment
  • Design representsations(models) should be easily understandable
  • The design should be developed iteratively
  • Creation of a design model does not preclude an alige approach

Living Modeling Principles

  • Stakeholder-centric models should target specific stakeholders and their tasks
  • Models and code should be closely coupled
  • Bidirectional information flow should be established between models and code
  • A common system view should be created
  • The imformation in the model must be presistent to allow tracking of system changes
  • Information consistency across all levels of the model must be verfied
  • Each model element has assigned stake holder rights and responsibilities
  • The states of virous model elements should be represented

Construction Principles

Preparation Principles

Before you write one line of code, be sure you

  • Understand the problem you are trying to solve
  • Understand the basic design principles and concepts
  • Pick a programming language that meets the needs of the software to be built and the environment in which it will operate
  • Select a prigramming environment that provides tools that will make your work easier
  • Create a set of unit tests that will be applied once the component you code is complete

Coding Principles

As you begin writing code, be sure you

  • Constrain your algorithms by following structured programming practive
  • Consider the use of pair programming
  • Select data structure that will meet the needs of the design
  • Understand the software architecture and create interface that are consistent with it
  • Keep conditional logic as simple as possible
  • Create nested loops in a way that makes them easily testable
  • Select meaningful variable names and follow other local coding standards
  • Write code that is self-documenting
  • Create a visual layout(e.g., indentation and blank lines)that aids understanding

Validation Principles

After you have completed your first coding pass, be sure you

  • Conduct a code walkthrough when appropriate
  • Perform unit tests and correct errors you have uncovered
  • Refactor the code

Testing Principles

  • All tests should be traceable to customer requirements
  • Tets should be planned long before testing begins
  • The Pareto principle applies to software testing
  • Testing should begin "in the small" and progress toward testing "in the large"
  • Apply to each module in the system a testing effort commensurate with its expected fault density
  • Static testing techniques can yield high results
  • Track defects and look for patterns in defects uncovered by testing
  • Include test cases that demonstrate software is behaving correctly

Deployment Principles

  • Customer expectations for the software must be managed
  • A complete delivery package should be assemabled and tested
  • A suppoer regime must be established before the software is delivered
  • Appropriate instructional materials must be provided to end users
  • Buggy software should be fixed first, delivered later

Analysis Rules of Thumb

  • The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.
  • Each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system.
  • Delay consideration of infrastructure and other nonfunctional models until design.
  • Minimize coupling throughout the system.
  • Be certain that the requirements model provides value to all stakeholders.
  • Keep the model as simple as it can be.

Class-Responsibility-Collaborator Modeling

  • Classes
  • Responsibilities
    • System intelligence should be distributed across classes to best address the need of the problem
    • Each responsibility should be stated as generally as possible
    • Information and the behavior related to it should reside within the same class
    • Information about one thing should be localized with a single class, not distributed across mutiple classes
    • Responsibilites should be shared among related classes, when appropriate
  • Collaborations

Requirements Modeling

  • Content model
  • Interaction model
  • Functional model
  • Navigation model
  • Configuration model

Quality Attributes FURPS

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

Characteristics of well-formed design class

  • Complete and sufficient
  • Primitiveness
  • High cohesion
  • Low coupling

Taxonomy of Architectural Stytles

  • Data-Centered Architectures
  • Data-Flow Architectures
  • Call and Return Architectures
  • Object-Oriented Architectures
  • Layered Architectures

Architectural Considerations

  • Economy
  • Visibility
  • Spacing
  • Symmetry
  • Emergence

Conducting Component-Level Design

  • Step1. Indentity all design classes that correspond to the problem domain
  • Step2. Undetify all design classes that correspond to the infrastructure domain
  • Step3. Elaborate all design classes that are not acquired as resuable components
  • Step3a. Specify message details when classes or components collaborate
  • Step3b. Indentify appropriate interfaces for each component
  • Step3c. Elaborate attributes and define data types and data structures required to implement them
  • Step3d. Describe processing flow within each operation in detail
  • Step4. Describe persistent data sources (databases and files) and identity the classes required to manage them
  • Step5. Develop and elaborate behaviroal representations for a class or component
  • Step6. Elaborate deployment diagrams to provide additional implementation detail
  • Step7. Refactor every component-level design representation and always consider alternatives

The Golden Rules of User Interface Design

  • Place the User in Control
    • Define interaction modes in a way that does not force a user into unecessary or undesired actions
    • Provide for flexible interactions
    • Allow user interaction to be interruptible and undoable
    • Streamline interaction as skill levels advance and allow the interaction to be customized
    • Hide technical internals from the casual user
    • Design for direct interaction with objects that appear on the screen
  • Reduce the User's Memory Load
    • Reduce demand on short-term memory
    • Establish meaningful defaults
    • Define shortcuts that intuitive
    • The visual layout of the interface should be based on a real-world metaphor
    • Disclose information in a progressive fashion
  • Make the Interface Consisitent
    • Allow the user to put the current task into a meaningful context
    • Maintain consistency across a complete product line
    • If past interactive models have created user expections, do not make changes unless there is a compelling reason to do so

Design Issues

  • Response Time
  • Help Facilities
  • Error Handling
  • Menu and Command Labeling
  • Application Accessibility
  • Internationlization

Interface Design Principles

  • Principles that lead to better usability
    • Anticipation
    • Communication
    • Consistency
    • Controlled Autonomy
    • Efficiency
    • Flexibility
    • Focus
    • Human Interface Objects
    • Latency Reduction
    • Learnability
    • Metaphors
    • Readability
    • Track State
    • Visible Navigation
  • Dont's
    • Don't force the user to read voluminous amounts of text, particularly when the text explains the operation of the WebApp or assists in navigation
    • Don't make users scroll unless it is absolutely unavoidable
    • Don't rely on browser functions to assist in navigation
    • Don't allow aesthetics to supersede functionality
    • Dont' force the user to search the display to dertermine how to link to other content or services

Interface Design Workflow for Web and Mobile Apps

  • Review information contained in the requirements model and refine as required
  • Develop a rough sketch of the WebApp interface layout
  • Map user objectives into specific interface actions
  • Define a set of user tasks that are associated with each action
  • Storyboard screen images for each interface action
  • Refine interface layout and toryboards using input from aesthetic design
  • Indetify user interface objects that are required to implement the interface
  • Develop a procedural representation of the user's interface with the interface
  • Develop a behanvioral representation of the interface
  • Describe the interface layout for each state
  • Refine and review the interface design model

Design Tasks

  • Examine the requirements model and develop a problem hierarchy
  • Determine if a reliable pattern language has been developed for the problem domain
  • Beginning with a board problem, determine whether one or more architectural patterns are avaliable for it
  • Using the collaborations provided for the architectural patterns, examine subsystem or component-level problems and search for appropriate patterns to address them
  • Repeat steps 2 through 4 until all broad problems have been addressed
  • If user interface design problems have been isolated (this is almost always the case), search the many user interface design pattern repositories for apporiate patterns
  • Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual pattern shows promise, compare the problem to be solved against the existing pattern(s) presented
  • Be certain to refine the design as it is derived from patterns using design quality criteria as a guide

Design Focus

  • Information architecture patterns
  • Navigation patterns
  • Interaction patterns
  • Presentation patterns
  • Functional patterns

WebApp Design Quality

  • Usability
  • Functionality
  • Reliability
  • Efficiency
  • Maintainability
  • Security
  • Availability
  • Scalability
  • Time-to-Market

Design Goals

  • Simplicity
  • Consistency
  • Indentity
  • Robustness
  • Navigability
  • Visual Appeal
  • Compatibility

Layout Guidelines

  • Don't be afraid of open space
  • Emphasize content
  • Organize layout elements from top left to bottom right
  • Group navigation, content, and function geographically within the page
  • Don't extend your real estate with the scrolling bar
  • Consider resolution and browser window size when designing layout

Mobile-Apps Technical Considerations

  • Multiple hardware and software platforms
  • Many development frameworks and programming languages
  • Many app stores with different rules and tools
  • Very short development cycles
  • UI limitations and complexities of iteraction with sensors and cameras
  • Effective use of content
  • Power management
  • Security and privacy models and policies
  • Computational and storage limitions
  • Applications that depend on external services
  • Testing complexity

MobileApps Spiral Engineering Process

  • Formulation
  • Planning
  • Analysis
  • Engineering
  • Implementation and Testing
  • User Evaluation

MobileApp Design - Best Practices

  • Indentify your audience
  • Design for context of use
  • There is a fine line between simplicty and laziness
  • Use the platform as an advantage
  • Make scrollbars and selection highlighting more salient
  • Increase discoverability of advanced functionality
  • Use clear and consistent labels
  • Clever icons should never be developed at the expense of users understanding
  • Support user expections for personalization
  • Long scrolling forms trump multiple screens on mobile devices

Mobile Interactive Development Environments(MIDEs) Criteria

  • General productivity features
  • Third-party SDK integration
  • Post-compilation tools
  • Over-the-air deployment support
  • End-to-end mobile application development
  • Graphical user interface builders

Gravin's Quality Dimensions

  • Performance Quality
  • Feature quality
  • Reliability
  • Conformance
  • Durability
  • Serviceability
  • Aesthetics
  • Perception

McCall's software quality factors

  • Product Operation
    • Correctness
    • Reliability
    • Efficiency
    • Integrity
    • Usability
  • Product Revision
    • Maintainability
    • Flexibility
    • Testability
  • Product Transition
    • Portability
    • Reusability
    • Interoperability

ISO 9126 Quality Factors

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

About

Notes & Essentials of Software Engineering: A Practitioner's Approach 8th edition

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published