CPSC 362 Midterm Terms

Coupling

a qualitative measure of how closely the classes in a design class diagram are linked

Behavioral Modeling

•A behavioral model indicates how software will respond to internal or external events or stimuli. •This information is useful in the creation of an effective design for the system to be built. •U M L activity diagrams can be used to model how system elements respond to internal events. •U M L state diagrams can be used to model how system elements respond to external events.

Testing Principles

1. All tests be traceable to customer requirements 2. Tests should be 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 3. The Pareto principle applies to software testing 4. Testing should begin "in the small" and progress toward testing "in the large." 5. Exhaustive testing is not possible. 6. Testing effort for each system module commensurate to expected fault density. 7. Static testing can yield high results. 8. Track defects and look for patterns in defects uncovered by testing. 9. Include test cases that demonstrate software is behaving correctly.

Principles that guide Process

1. Be agile 2. Focus on quality at every step 3. Be ready to adapt 4. Build an effective team 5. Establish mechanisms for communication and coordination 6. Manage change 7. Assess risk 8. Create work products that provide value for others

Deployment Principles

1. Customer expectations for the software must be managed 2. A complete package should be assembled and tested 3. A support regime must be established before the software is delivered 4. Appropriate instructional materials must be provided to end-users 5. Buggy software should be fixed first, delivered later

Principles that Guide Practice

1. Divide and conquer 2. Understand the use of abstraction 3. Strive for consistency 4. Focus on the transfer of information 5. Build software that exhibits effective modularity 6. Look for patterns 7. Use multiple viewpoints 8. Some consumes your work products

Communications Principles

1. Listen 2. Prepare before you communicate 3. Someone should facilitate the activity 4. Face-to-face communication is best 5. Take notes and document decisions 6. Strive for collaboration 7. Stay focused, modularize your discussion 8. If something is unclear, draw a picture 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 10. Negotiation is not a contest or a game. It works best when both parties win

Requirement Modeling Principles

1. The information domain of a problem must be represented and understood 2. The functions that the software performs must be defined 3. The behavior of the software (as a consequence of external events) must be represented 4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion 5. The analysis task should move from essential information toward implementation detail

Essence of Software Engineering Practice

1. Understand the problem 2. Plan a solution 3. Carry out the plan 4. Examine result for accuracy

Construction Principles - Coding

1. Understand the problem to be solved 2. Understand basic design principles and concepts 3. Pick a programming language that meets the needs of the software to be built 4. Select a programming environment that provides tools that will make your work easier 5. Create a set of unit tests that will be applied once the component you code is completed 6. Constrain your algorithms by following structured programming practice 7. Consider the use of pair programming 8. Select data structures that will meet the needs of the design 9. Understand the software architecture and create the interfaces that are consistent with it After finish coding: 10. Conduct a code walkthrough when appropiate 11. Perform unit tests and correct errors you've uncovered 12. Refactor the code to improve its quality

Planning Principles

1. Understand the scope of the project 2. Involve the customer in the planning activity 3. Recognize that planning is iterative 4. Estimate based on what you know 5. Consider risk as you define the plan 6. Adjust granularity as you define the plan 7. Define how you intend to ensure quality 8. Describe how you intended to accommodate 9. Track the plan frequently and make adjustments as required

Creating Behavioral Models

1.Evaluate all use cases to fully understand the sequence of interaction within the system. 2.Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3.Create a sequence diagram for each use case. 4.Build a state diagram for the system. 5.Review the behavioral model for accuracy and consistency.

What is a task set?

A task set defines the actual work to be done to accomplish the objectives of a software engineering action. This is defined by creating several lists: 1. A list of tasks to be accomplished 2. A list of the work products to be produced 3. A list of the quality assurance filters to be applied

Scenario-Based Modeling Actor and Profiles

Actors model an entity that interacts with a system object - represent roles played by human stakeholders or external hardware as they interact with system objects by exchanging information Profile provides a way of extending an existing model to other domains or platforms - allow to revise the model of a Web-based system and model the system for various mobile platforms - might be used to model the system from the viewpoints of different users

Software Equality

An effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it.

How is a process model used?

Any software process can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for successful software engineering

Architectural vs Component Patterns

Architectural patterns describe broad-based design problems that are solved using a structural approach Component patterns (design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture.

What is Design Pattern?

Design patterns provide a codified mechanism for describing problems and their solution in a way that allows the software engineering community to capture design knowledge for reuse.

Agile Process

Driven by customer description of what is required, 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

Identifying Analysis Classes

Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse". •Classes are determined by underlining each noun or noun phrase and entering it into a simple table. •Synonyms should be noted. •If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space. But what should we look for once all of the nouns have been isolated?

software

Instructions (computer programs) that when executed provide desired features, functions, and performances | data structures that enable the programs to adequately manipulate information | documentation that describes the operation and use of the programs

Pattern Descriptions

Intent—describes the pattern and what it does Collaborations—describes how other patterns contribute to the solution Consequences—describes the potential trade-offs that must be considered when the pattern is implemented and the consequences of using the pattern Implementation—identifies special issues that should be considered when implementing the pattern Known uses—provides examples of actual uses of the design pattern in real applications Related patterns—cross-references related design patterns

Components

Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model.

Spiral Process Model

Pros: 1. Continuous customer involvement 2. Development risks are managed 3. Suitable for large, complex projects 4. It works well for extensible products Cons: 1. Risk analysis failures can doom the project 2. Project may be hard to manage 3. Requires an expert development team

XP

Pros: 1. Emphasizes customer involvement 2. Establishes rational plans and schedules 3. High developer commitment to the project 4. Reduced likelihood of product rejection Cons: 1. Temptation to "ship" a prototype 2. Requires frequent meetings about increasing costs 3. Allows for excessive changes 4. Depends on highly skilled team members

Waterfall Process Model

Pros: 1. It is easy to understand and plan 2. It works for well-understood small projects 3. Analysis and testing are straightforward Cons: 1. It does not accommodate change well 2. Testing occurs late in the process 3. Customer approval is at the end

KanBan

Pros: 1. Lower budget and time requirements 2. Allows early product delivery 3. Process policies written down 4. Continuous process involvement Cons: 1. Team collaboration skills determine success 2. Poor business analysis can doom the projects 3. Flexibility can cause developers to lose focus 4. Developer reluctance to use measurement

Unified Process Model

Pros: 1. Quality documentation emphasized 2. Continuous customer involvement 3. Accommodates requirements changes 4. Works well for maintenance projects Cons: 1. Use cases are not always precise 2. Tricky software increment integration 3. Overlapping phases can cause problems 4. Requires expert development team

Prototyping Process Model

Pros: 1. Reduced impact of requirement changes 2. Customer is involved early and oftern 3. Works well for small projects 4. Reduced likelihood of product rejection Cons: 1. Customer involvement may cause delays 2. Temptation to "ship" a prototype 3. Work lost in a throwaway prototype 4. Hard to plan and manage

DevOps

Pros: 1. Reduced time to code deployment 2. Team has developers and operations staff 3. Team has end-to-end project ownership 4. Proactive monitoring of deployed product Cons: 1. Pressure to work on both old and new code 2. Heavy reliance on automated tools to be effective 3. Deployment may affect the production environment 4. Requires an expert development team

Scrum

Pros: 1. Product owner sets priorites 2. Team owns decision making 3. Documentation is lightweight 4. Supports frequent updating Cons: 1. Difficult to control the cost of changes 2. May not be suitable for large teams 3. Requires expert team members

What is Software?

Software is developed or engineered it is not manufactured in the classical sense | doesn't wear out but it does deteriorate | continues to be custom-built

What is software engineering?

The application of a systematic, disciplined, quantified approach to the development, operation, and maintenance of software; that is, the application of engineering to software

What is architecture

The architecture is not the operational software, it is a representation that enables a software engineer to: 1.Analyze the effectiveness of the design in meeting its stated requirements, 2.Consider architectural alternatives at a stage when making design changes is still relatively easy, and 3.Reduce the risks associated with the construction of the software.

Informal Reviews

The benefit is immediate discovery of errors and better work product quality. Informal reviews include: •A simple desk check of a software engineering work product with a colleague. •A casual meeting (involving more than 2 people) for the purpose of reviewing a work product, or •The review-oriented aspects of pair programming which encourages continuous review as work is created.

What is requirement engineering?

The process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system.

Layers of Software Engineering

Tools, Methods, Process,A quality focus

Formal Review

Walkthrough are: 1.To uncover errors in function, logic, or implementation for any representation of the software. 2.To verify that the software under review meets its requirements. 3.To ensure that the software has been represented according to predefined standards. 4.To achieve software that is developed in a uniform manner. 5.To make projects more manageable.

Reviews

What are they? •A meeting conducted by technical people. •A technical assessment of a work product created during the software engineering process. •A software quality assurance mechanism. •A training ground. What they are not! •A project summary or progress assessment. •A meeting intended solely to impart information. •A mechanism for political or personal reprisal!

What is Quality

a characteristic or attribute of something

Class-Based Modeling

represents: - objects that the system will manipulate - operations (methods or services) that will be applied to the objects to effect the manipulation - relationships between the objects - collaborations that occur between the classes that are defined The elements of a class-based model include classes and objects, attributes, operations, C R C models, U M L class diagrams.

What is Cohesion?

that a component encapsulates only attributes and operations that are closely related to one another and the component itself

Design Concepts

•Abstraction - data (named collection of data describing data object), procedural (name sequence of instructions with specific and limited function). •Architecture - overall structure or organization of software components, ways components interact, and structure of data used by components. •Design Patterns - describe a design structure that solves a well-defined design problem within a specific context. •Separation of concerns - any complex problem can be more easily handled if it is subdivided into pieces. •Modularity—compartmentalization of data and function. •Information Hiding - controlled interfaces which define and enforces access to component procedural detail and any local data structure used by the component. •Functional independence - single-minded (high cohesion) components with aversion to excessive interaction with other components (low coupling). •Stepwise Refinement - incremental elaboration of detail for all abstractions. •Refactoring—a reorganization technique that simplifies the design without changing functionality. •Design Classes—provide design detail that will enable analysis classes to be implemented.

Kinds of Patterns

•Architectural patterns describe broad-based design problems that are solved using a structural approach. •Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. •Component patterns (design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture. •Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end-users. •WebApp patterns address a problem set that is encountered when building WebApps and often incorporate many of other patterns categories. Mobile patterns describe solutions to problems commonly encountered when developing solutions for mobile platforms

How is architecture related to design?

•Architecture highlights early design decisions that will have a profound impact on all software engineering work that follows. •Architecture constitutes a relatively small, intellectually graspable mode of how the system is structured and how its components work together.

CRC Modeling

•Class-responsibility-collaborator (C R C) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. •A C R C model is really a collection of standard index cards that represent classes. •The cards are divided into three sections: 1.Along the top of the card you write the name of the class. 2.list the class responsibilities on the left. 3.list the collaborators on the right.

Software Defects

•Error—a quality problem found before the software is released to end users. •Defect—a quality problem found only after the software has been released to end-users. •We make this distinction because errors and defects have very different economic, business, psychological, and human impact. •Design activities introduce 50 to 65% of all software defects. •Review activities have been shown to be 75% effective in uncovering design flaws. •The sooner you find a defect the cheaper it is to fix it.

Potential Analysis Classes

•External entities (for example: other systems, devices, people) that produce or consume information. •Things (for example: reports, displays, letters, signals) that are part of the information domain for the problem. •Occurrences or events that occur within the context of system operation. •Roles played by people who interact with the system. •Organizational units that are relevant to an application. •Places that establish the context of the problem and overall function. •Structures (for example: sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.

Software Quality Dilemma

•If you produce a software system that has terrible quality, you lose because no one will want to buy it. •If you spend infinite time, extremely large effort, and huge sums of money to build a perfect piece of software, then it's going to take so long to complete and will be so expensive to produce that you'll be out of business. •You will either missed the market window, or you exhausted all your resources. •People in industry try to find that magical middle ground where the product is good enough not to be rejected right away, but also not the object of so much perfectionism that it would take too long or cost too much to complete.

Requirements engineering process

•Inception - establish a basic understanding of the problem, the people who want a solution, and the nature of the solution that is desired, important to establish effective customer and developer communication. •Elicitation - elicit requirements and business goals form from all stakeholders. •Elaboration - focuses on developing a refined requirements model that identifies aspects of software function, behavior, and information. •Negotiation—agree on the scope of a deliverable system that is realistic for developers and customers. •Specification—can be any or all of the following: written documents, graphical models, mathematical models, usage scenarios, prototypes. •Validation—Requirements engineering work products produced during requirements engineering are assessed for quality and consistency. •Requirements management - set of traceability activities to help the project team identify, control, and track requirements and their changes to requirements as the project proceeds.

Review Metrics

•Preparation effort, Ep — the effort (in person-hours) required to review a work product prior to the actual review meeting. •Assessment effort, Ea — the effort (in person-hours) that is expending during the actual review. •Rework effort, Er — the effort (in person-hours) that is dedicated to the correction of those errors uncovered during the review. •Work product size, W P S — a measure of the size of the work product that has been reviewed (for example: the number of U M L models, or the number of document pages, or the number of lines of code). •Minor errors found, Errminor — the number of errors found that can be categorized as minor (requiring less than some pre-specified effort to correct). •Major errors found, Errmajor — the number of errors found that can be categorized as major (requiring more than some pre-specified effort to correct). •Total errors found, Errtot. Represents the sum of the errors found: Errtot = Errminor + Errmajor •Error density. Represents the errors found per unit of work product reviewed: Error density = Errtot ÷ W P S

Cost of Quality

•Prevention costs - quality planning, formal technical reviews, test equipment, training. •Appraisal costs - conducting technical reviews, data collection and metrics evaluation, testing and debugging. •Internal failure costs - rework, repair, failure mode analysis. •External failure costs - complaint resolution, product return and replacement, help line support, warranty work

Quality in Software

•Quality of design encompasses requirements, specifications, and the design of the system. •Quality of conformance is an issue focused primarily on implementation. •User satisfaction = compliant product + good quality + delivery within budget and schedule.

Analysis Class Selection

•Retained information. Potential class will be useful during analysis only if information about it must be remembered. •Needed services. Potential class must have a set of identifiable operations that can change the value of its attributes in some way. •Multiple attributes. Focus should be on "major" information; a class with a single attribute may be better represented as an attribute of another class. •Common attributes. A set of attributes can be defined for the potential class and the attributes apply to all instances of the class. •Common operations. A set of operations can be defined for the potential class and the operations apply to all instances of the class. •Essential requirements. External entities that appear in the problem space and produce or consume information essential to the solution will usually be defined as analysis classes in the model.

Requirement Models

•Scenario-based models depict requirements from the point of view of various system "actors." •Class-oriented models represent object-oriented classes (attributes and operations) and how classes collaborate to achieve system requirements. •Behavioral models depict how the software reacts to internal or external "events." •Data models depict the information domain for the problem. •Flow-oriented models represent functional elements of the system and how they transform data in the system.

Defect Amplification

•describe how an defect introduced early in the software engineering work flow (for example: during requirement modeling) and undetected, can and often will be amplified into multiple errors during design and more errors in construction.

Requirements

•specifies software's operational characteristics. •indicates software's interface with other system elements. •establishes constraints that software must meet.