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)