Software Engineering Midterm
What is Agility?
- Effective (rapid and adaptive) response to change - Effective communication with stakeholders - Bring customer onto team - Organizing a team so that it is in control of the work performed. - Rapid, incremental software delivery
Analysis Patterns
-Pattern Name -Intent -Motivation -Forces and Context -Solution -Consequences -Design -Known uses -Related Patterns
Scrum Framework
-Roles: Product Owner, Scrum Master, Team -Ceremonies: Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum meeting -Artifacts: Product Backlog, Sprint Backlog, Burndown Charts
Design Engineering
Organization responsible for the design of a company's product or service.
UML Profile
Provides a way of extending an existing model to other domains or platforms.
Effective Software Team Attributes
Sense of purpose Sense of involvement Sense of trust Sense of improvement Diversity of team member skill sets
What is Software Architecture?
Set of principal design decisions about the system Blueprint for its construction and evolution
Operations
The behavior of an object
Master-Slave
an asymmetric multiprocessing configuration consisting of a single processor system connected to "slave" processors, each of which is managed by the primary "master" processor, which provides the scheduling functions and jobs.
What is an Agile Process?
- Driven by customer descriptions of what is required (scenarios) - Customer feedback is frequent and acted on. - Recognizes that plans are short-lived - Develops software iteratively with a heavy emphasis on construction activities. - Delivers multiple 'software increments' as executable prototypes. - Adapts as project or technical changes occur
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 uncovers detail in a layered fashion. -The analysis task should move from essential information toward implementation detail.
Deployment Principles
- manage customer expectations for each increment - a complete delivery package should be assembled and tested - a support regime should be established - instructional materials must be provided to end-users - buggy software should be fixed first, delivered later
Quality Guidelines
-A design should exhibit an architecture. -Should be modular -Should contain distinct representations of data, architecture, interfaces, and components. -Lead to data structures that are drawn from recognizable data patterns -Contain functionally independent components. -Lead to interfaces that reduce the complexity of connections between components and the external environment. -Be represented using meaningful notation.
Identifying a Task Set
-A list of the tasks to be accomplished -A list of the work products to be produced -A list of the quality assurance filters to be applied
Common Design Characteristics
-A mechanism for the translating the requirements model into a design representation. -A notation for representing functional components and their interfaces. -Heuristics for refinement and partitioning. -Guidelines for quality assessment.
Design Concepts
-Abstraction -Architecture -Design Patterns -Separation of concerns -Modularity -Information Hiding -Functional Independence -Stepwise Refinement -Refactoring -Design Classes
Design Class Characteristics
-Complete -Primitiveness: Each class method focuses on providing one service. -High Cohesion: Small, Focused, single-minded classes. -Low Coupling: Class collaboration kept to minimum.
Software Engineering Design
-Data/Class Design: Transforms analysis classes into implementation classes and data structures. -Architectural Design: Defines relationships among the major software structural elements. -Interface design: Defines how software elements, hardware elements, and end-users communicate. -Component-Level Design: Transforms structural elements into procedural descriptions of software components.
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 must be designed with care. -User interface design should be tuned to the needs of the end-user and stress ease of use. -Component-level design should be functionally independent -Components should be loosely coupled to each other than the environment. -Design representations should be easily understandable -The design should be developed iteratively -Creation of a design model does not preclude using an agile approach.
Project Factors Affecting Team Structure
-Difficulty of the problem to be solved. -Resultant program size in lines of code or function points. -Time that the team will stay together (team lifetime) -Degree to which the problem can be modularized. -Required quality and reliability of the system to be built. -Rigidity of the delivery date. -Degree of communication required for the project.
Symptoms of Team Toxicity
-High frustration that causes friction among team members. -A frenzied work atmosphere where team members waste energy and lose focus on work objectives. -Fragmented or poorly coordinated software process model that becomes a roadblock to accomplishment. -Unclear definition of team roles resulting in a lack of accountability and resultant finger-pointing. -Continuous and repeated exposure to failure that leads to a loss of confidence and poor morale.
Testing Principles
-Principle 1: All tests should be traceable to customer requirements. -Principle 2: Tests should planned long before testing begins. - Testing is a process of executing a program with intent of finding an error. -A good test case is one that has a high probability of finding an as-yet-undiscovered error. -A successful test is one that uncovers an as-yet-undiscovered error. -Principle 3: The Pareto principle applies to software testing. -Principle 4: Testing should begin "in the small" and progress toward testing "in the large". -Principle 5: Exhaustive testing is not possible -Principle 6: Testing effort for each system module commensurate to expected fault density. -Principle 7: Static testing can yield high results. -Principle 8: Track defects and look for patterns in defects uncovered by testing. -Principle 9: Include test cases that demonstrate software is behaving correctly.
Principles that Guide Process
-Principle 1: Be agile. -Principle 2: Focus on quality at every step -Principle 3: Be ready to adapt -Principle 4: Build an effective team -Principle 5: Establish mechanisms for communication and coordination. -Principle 6: Manage change -Principle 7: Assess risk -Principle 8: Create work products that provide value for others.
Communication Principles
-Principle 1: Listen -Principle 2: Prepare before you communicate -Principle 3: Someone should facilitate the activity -Principle 4: Face-to-face communication is best -Principle 5: Take notes and document decisions -Principle 6: Strive for collaboration -Principle 7: Stay focused, modularize your discussion -Principle 8: If something is unclear, draw a picture -Principle 9: Once you agree to something, move on; (b) If you can't agree to something, move on; (c) If a feature or function is unclear and cannot be clarified at the moment, move on. -Principle 10: Negotiation is not a contest or a game. It works best when both parties win.
Agile Modeling Principles
-Principle 1: The primary goal of the software team is to build software not create models. -Principle 2: Travel light - don't create more models than you need. -Principle 3: Strive to produce the simplest model that will describe the problem or the software. -Principle 4: Build models in a way that makes them amenable to change. -Principle 5: Be able to state an explicit purpose for each model that is created. -Principle 6: Adapt the models you create to the system at hand. -Principle 7: Try to build useful models, forget about building perfect models. -Principle 8: Don't become dogmatic about model syntax. Successful communication is key. -Principle 9: If your instincts tell you a paper model isn't working you may have a reason to be concerned. -Principle 10: Get feedback as soon as you can.
Planning Principles
-Principle 1: Understand the scope of the project -Principle 2: Involve the customer in the planning activity. -Principle 3: Recognize that planning is iterative. -Principle 4: Estimate based on what you know. -Principle 5: Consider risk as you define the plan. -Principle 6: *This is missing in slides* -Principle 7: Adjust granularity as you define the plan. -Principle 8: Define how you intend to ensure quality. -Principle 9: Describe how you intend to accommodate change. -Principle 10: Track the plan frequently and make adjustments as required
Principles that Guide Practice
-Principle 1: divide and conquer -Principle 2: understand the use of abstraction -Principle 3: strive for consistency -Principle 4: focus on the transfer of information -Principle 5: build software that exhibits effective modularity -Principle 6: look for patterns -Principle 7: represent the problem and its solution from a number of different perspectives -Principle 8: remember that someone will maintain the software
Team Decision Making Complications
-Problem complexity -Uncertainty and risk associated with the decision. -Work associated with decision has unintended effect on another project object. -Different views of the problem lead to different conclusions about the way forward. -Global software teams face additional challenges associated with collaboration, coordination, and communication difficulties.
Steps for Design Engineering
-Represent the architecture -Design the interfaces -Design components -Repeat
Analysis Class Selection
-Retained Information -Needed Services -Multiple Attributes -Common Attributes -Common Operations -Essential Requirements
Impact of Social Media
-Social processes around software development are highly depend on engineers' abilities to connect with individuals who share similar goals and complementary skills. -Privacy and security issues should not be overlooked when using social media for software engineering work. -Benefits of social media must be weighed against the threat of uncontrolled disclosure of proprietary information.
Requirement Analysis
-Specifies software's operational characteristics -Indicates software's interface with other system elements. -Establishes constraints that software must meet.
Architecture Properties
-Structural Properties -Extra-Functional Properties -Families of related systems.
Kanban Framework
-Visualizing workflow using Kanban board -Limiting the amount of work in progress at any given time. -Managing workflow to reduce waste by understanding the current value flow. -Making process policies explicit and the criteria used to define "done" -Focusing on continuous improvement by creating feedback loops where changes are introduced. -Make process changes collaboratively and involve all stakeholders as needed.
CRC Model Review Process
1. All stakeholders in the review are given a subset of the CRC cards. 2. The review leader reads the use case deliberately. 3. When the token is passed, the holder of the class card is asked to describe the responsibilities satisfies the use case requirements. 4. If an error is found, modifications are made to the cards.
Two phase Process to determine NFR
1. Create a matrix using each NFR as a column heading and the system SE guidelines a row labels. 2. Prioritize each NFR using a set of decision rules to decide which to implement.
What is Software?
1. Instructions for a computer. 2. Data structures that enable the programs to manipulate information. 3. Documentation that describes the operation and use the programs.
Essence of Software Engineering Practice (Polya Suggests)
1. Understand the problem 2. Plan a solution 3. Carry out the plan 4. Examine result for accuracy
Functional Modeling
1. User-observable functionality that is delivered by the app to end users. 2. Operations contained within analysis classes that implement behaviors associated with the class.
Attributes
A class that has been selected for inclusion in the analysis model.
Use Case Definition
A collection of user scenarios that describe the thread of usage of a system.
Output of Design Engineering / Software Engineering
A document called Software Design Description (SDD) -Serves as the blueprint for the implementation phase. -Describes the components of a system, the modules that comprise each component, and the detailed information.
Exception
A situation (either a failure condition or an alternative chosen by the actor) that causes the system to exhibit somewhat different behavior.
Batch Sequential
A traditional data processing model that was widely used in 1950 - 1970. Sequential: Each data transformation component cannot start its process until its previous component completes its computation. Data flow carries a batch of data as a whole to move from one component to another
Sequence Diagram
A type of diagram that shows objects participating in interactions and the messages exchanged between them.
Software Release Maintenance
Activities needed to keep software operational after it has been accepted and released in end-user environment
Why must software change
Adapted to new computers Enhanced to implement business requirements Extended to make it interoperable with other more modern systems or databases. Re-Architected to make it viable within a network
Data Centered Architectures
Centralized data store which is shared by a group of software components -Repository -Blackboard
Perfective Maintenance
Changes made to a system to add new features or to improve performance.
Process Framework Activities
Communication Planning Modeling -Analysis of requirements -Design Construction -Code generation -Testing Deployment
DevOps Framework
Continuous Development - Software delivered in multiple sprints. Continuous Testing - Automated testing tools used prior to integration. Continuous Integration - Code pieces with new functionality added to existing code running code. Continuous Deployment - Integrated code is deployed to the production environment Continuous Monitoring - Team operations staff members proactively monitor software performance in the production environment
Process Control Data
Controlled variable: target controlled variable such as speed in a cruise control system or the temperature in an auto H/A system. Input variable: measured input data such as the temperature of return air in a temperature control system. Manipulated variable: can be adjusted by the controller.
Class-Based Modeling
Defines the objects a system manipulates, operations applied to objects, and the collaborations occurring between classes.
Requirements Monitoring
Distributed Debugging - Uncovers errors and determines their cause. Run-time verification - Determines whether software matches its specification. Run-time validation - Assesses whether the evolving software meets user goals Business activity monitoring - Evaluates whether a system satisfies business goals. Evolution and codesign - Provides information to stakeholders as the system evolves.
Main-Subroutine
Dominated the software design methodologies for a very long time. Reuse the subroutines and have individual subroutines developed independently. In the classical procedural paradigm, typically data are shared by related subroutines at the same level. With OOP, the data is encapsulated in each individual object so that the information is protected.
Architectural Styles
Each style describes a system category that encompasses: -Set of components -Set of connectors -Constraints -Semantic models
Analysis Classes
Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse".
Data Flow Architecture
Filters and transforms inputs into outputs -Batch Sequential -Pipe and Filter -Process Control
Requirements Engineering Tasks
Inception Elicitation Elaboration Negotiation Specification Requirements Validation Requirements Management
Behavioral Modeling
Indicates how software will respond to internal or external events or stimuli.
Call and Return Architecture
Main program invokes controller subprograms
UML Actor
Models an entity that interacts with a system object.
Pipe and Filter
Modularity, reuse, anticipation of change
Construction Principles - Coding
Preparation Principles: -Principle 1: Understand the problem to be solved. -Principle 2: Understand basic design principles and concepts. -Principle 3: Pick a programming language that meets the needs of the software to be built. -Principle 4: Select a programming environment that provides tools that will make your work easier. -Principle 5: Create a set of unit tests that will be applied once the component you code is completed. Coding Principles: -Principle 6: Constrain your algorithms by following structured programming practice. -Principle 7: Consider the use of pair programming. -Principle 8: Select data structures that will meet the needs of the design. -Principle 9: Understand the software architecture and create interfaces that are consistent with it. Validation Principles: -Principle 10: Conduct a code walkthrough when appropriate. -Principle 11: Perform unit tests and correct errors you've uncovered. -Principle 12: Refactor the code to improve its quality.
Preventive Maintenance
Proactive modification software after delivery to correct product faults before discovery by users.
Spiral Process Model
Pros -Continuous customer involvement -Development risks are managed -Suitable for large, complex projects -It works well for extensible products Cons -Risk analysis failures can doom the project -Project may be hard to manage -Requires an expert development team
Waterfall Process Model
Pros -It is easy to understand and plan -It works for well-understood small projects -Analysis and testing are straightforward Cons -It does not accommodate change well. -Testing occurs late in the process. -Customer approval is at the end.
Unified Process Model
Pros -Quality documentation emphasized -Continuous customer involvement -Accommodated requirements changes -Works well for maintenance projects Cons -Use cases are not always precise -Tricky software increment integration -Overlapping phases can cause problems -Requires expert development team
Prototyping Process Model
Pros -Reduced impact of requirement changes -Customer is involved early and often -Works well for small projects -Reduced likelihood of product rejection Cons -Customer involvement may cause delays -Temptation to "ship" a prototype -Work lost in a throwaway prototype -Hard to plan and manage
Class-Responsibility-Collaborator (CRC) Modeling
Provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. -Really a collection of standard index cards that represent classes.
Corrective Maintenance
Reactive modification of a software product performed after delivery to correct discovered problems
Adaptive Maintenance
Reactive modification of software after delivery to keep the software usable in a changing environment
Hooker's General Principles
Reason it all exists KISS Maintain the vision What you produce, others will consume Be open to the future Plan ahead for reuse Think
Analysis Model Elements
Scenario-based elements (use cases describe system from user perspective) Class-based elements (relationships among objects manipulated by actors and their attributes are depicted as classes) Behavioral elements (depict system and class behavior as states and transitions between states) Flow-oriented elements (shows how information flows through the system and is transformed by the system functions)
Input of Design Engineering / Software Engineering
Software Requirements Specification (SRS) -The result of requirement analysis; it records the functional and non-functional requirements that must be met by the software system.
Java Virtual Machine (JVM)
Software that allows a Java program to run on a wide variety of operating systems.
Software Application Domains
System Software Application Software Engineering/Scientific Software Embedded Software Product-Line Software Web/Mobile Applications AI Software
Virtual Machine
The apparent machine that the operating system presents to the user, achieved by hiding the complexities of the hardware behind layers of operating system software.
IEEE Definition of Software Engineering
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
Process Control Architecture
The process-control software architecture is suitable for the embedded system software design where the system is manipulated by a process control variable data. Decomposes the whole system into Components (modules) and connections.
Non-Functional Requirements (NFR)
The quality attributes, design and implementation constraints, and external interfaces that the product must have.
Layered Architecture
The system is decomposed into a number of higher and lower layers in a hierarchy Each layer consists of a group of related classes that are encapsulated in package, in a deployed component, or as a group of subroutines in the format of method library or header file. Each layer has its own responsibility in the system.
Software Engineering Layers
Tools Methods Process A Quality Focus
Hierarchical Architectures
Views the SW as a hierarchy structure The software system is decomposed into logical modules (sub-systems) at different levels in the hierarchy. Modules at different levels are connected by method invocations A lower level module provides services to its adjacent upper level modules, which invokes the methods or procedures in lower level. Main Types: -Main-subroutine, master-slave, and layered architectures
Extreme Programming (XP) Framework
XP Planning - User stories, team estimates cost, stories grouped into increments, commitment made on delivery date, computer project velocity. XP Design - Follows KIS principle, encourages use of CRC cards, design prototypes, refactoring. XP Coding - Construct unit tests. XP Testing - Unit tests executed daily, acceptance tests define by customer.
Use Case
an activity that the system performs, usually in response to a request by a user
Swimlane Diagram
documents the steps or activities of a workflow by grouping activities into swimlanes, which are horizontal or vertical columns containing all associated activities for that category or department
Requirements Models
· Scenario-based (system from the user's point of view) · Data (shows how data are transformed inside the system) · Class-oriented (defines objects, attributes, and relationships) · Flow-oriented (shows how data are transformed inside the system) · Behavioral (show the impact of events on the system states)