Final Flashcards Preview

Software Engineering > Final > Flashcards

Flashcards in Final Deck (82):
1

Software crisis

Refers to the difficulty of writing useful and efficient computer programs in the required time.

2

Symptoms of a software crisis

- Over-budget projects
- Late projects
- Inefficient projects
- Low quality software
- Software that did not meet requirements
- Unmanageable projects
- Difficult to maintain code
- Never delivered software

3

IEEE definition of software engineering

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Systematic - done or acting to a fixed plan; methodical
Disciplined - showing a controlled form of behavior or way of working
Quantifiable - capable of being measured

Development - the approach to making the software
Operation - the approach to how the software works
Maintenance - the approach to "fixing" the software

4

The four P's of software engineering

People - project stakeholders
Product - the software being produced, and associated documentation
Project - the activities performed to create the product
Process - the framework within which the team carries out the activities necessary to build the project

5

Software development lifecycle

- Inception
- Requirements gathering and analysis
- Design
- Implementation
- Testing
- Deployment
- Maintenance

6

Inception

Goal:
Determine the problem being solved

Sub-goals:
- Identity the system that is needed
- Identify high-level functionality
- Identity how the system fits into the client's ecosystem?

7

Requirements

Goal:
Find out and record exactly what the software should do

Sub-goals:
- Find out what the software should not do
- Determine all stakeholders
- Produce requirements documentation
- Do an initial analysis model
- Review requirements with stakeholders to ensure correctness and completeness

8

Design

High-level goal:
Determine the architecture of the application

Low-level goal:
Determine algorithms and data structures used to implement the system and architecture

9

Implementation

Goal:
Write code

Sub-goals:
- Unit and integration testing

10

Testing

Goal:
Validate that the requirements are satisfied by the software

Sub-goals:
- Verification and validation (V&V)
- Unit testing
- Integration testing
- Regression testing
- Acceptance testing

11

Deployment

Goal:
Delivery to client

12

Maintenance

Goal:
Fix bugs, update software, add/subtract features, etc.

13

Why use life-cycle models

- Helps to organize, plan, staff, budget, and schedule
- Outlines documents and deliverables
- Helps set milestones
- Describes what tools and staffing are needed
- Helps measure cost, quality and productivity per process
- Helps the organization improve the quality of the process

14

Describe the waterfall model

- Requirements specification
- Design
- Implementation
- Testing
- Deployment
- Maintenance

- Documentation for each phase is the input for the next phase
- Each phase must be completed before the next phase
- Each deliverable becomes a milestone
- Document driven
- Sequential

15

Incremental model

- Repeatedly execute the full development cycle on small chunks
- Each increment releases a useful feature
- Requires a well-partitioned design
- Drawback: you may no know if the entire system works until the end

16

Iterative model

- Repeatedly execute the full development cycle
- Add depth to the system on each round
- User has a working system from the beginning
- Feature-rich releases come later

17

Agile methods

- Iterative and incremental
- Agile Manifesto removes the focus from strict documentation to faster releases
- Small, close-knit teams
- Regular, frequent, disciplined customer requirements meetings
- A code-centric approach with documentation as-needed
- Customer representatives working within the team
- The use of user stores for requirements
- Refactoring
- Pair programming
- Continual unit testing and acceptance testing

18

Scrum

- An agile model
- Project management based approach
- Get the user requirements in the form of user stories but not all at once
- Estimate the effort for each user story
- Keep a backlog for user stories
- For each iteration only attempt what can be done in one iteration
- Iterations are a maximum of one month

19

Describe Extreme Programming (XP)

- Incremental planning: User Stories on Story Cards, prioritized for a release
- Small releases: the smallest possible set of functionality that provides value is developed first
- Simple design: Only design what you're currently working on and do no more
- Test-driven development: write automated unit tests before the implementation of the functionality
- Refactoring: make code simple and refactor it often
- Pair programming: developers work in teams of two, checking each other's work and providing support
- Collective ownership: developer pairs work on all areas of the system to prevent "islands of expertise"
- Continuous integration: as soon as a task is complete, it is integrated into the entire system; requires all unit tests to pass for the entire system
- Sustainable pace: overtime is not a common practice because it can reduce code quality
- On-site customer: the customer should be available to the XP team at all times; the customer representative becomes a member of the development team
- Coding standard: the team agrees to follow a specific set of rules regarding development style throughout the project; XP advocates self-documenting code as much as possible
- System metaphor: the metaphor is a story that every stakeholder can tell about how the system works; this extends to naming classes and methods in a way that describes their intended used and relates to the issue of self-documenting code

20

Rational Unified Process (RUP)

- Designed to sit between heavyweight and agile methods
- Use-case driven
- Architecture-centric
- Iterative and incremental

- Inception: develop a business case for the system
- Elaboration: refine the initial requirements, refine the architecture, and monitor the risks and refine their priorities
- Construction: programming and implementation with integral testing activities
- Transition: move the system from the development environment to the real environment

21

How to pick a life-cycle model

- Inertia: we've always used this method (typically not a good mindset)
- Market hype: everyone is using method x, so we should too
- Size/complexity analysis: agile methods may not work for large projects
- Best practice analysis

22

Capability Maturity Model Integration (CMMI)

Purpose:
Rate an organization's process maturity

Consists of 5 levels:
0 - Incomplete
1 - Initial
2 - Managed
3 - Defined
4 - Quantitatively Managed
5 - Optimizing

Incomplete:
- You basically just do it

Initial:
- Undefined/Ad Hoc
- Unpredictable
- Depends on team members
Usually over budget and past due

Managed:
- Measurement/Control
Prediction is possible through quantitative means

Defined:
- Standardized process
- All projects are consistent in process
- Quantitatively predictable

Quantitatively Managed:
- Process measured
- Metrics available for the process

Optimized:
- Improvement process
- Process metrics lead to continuous improvement

23

Requirements Definition

A description of a service that the system is expected to provide and the constraints under which it must operate.

24

Sub-phases of the requirements proess

- Gathering
- Analysis
- Specification
- Validation

25

Requirements Gathering

- Customers
- Users
- Forms
- Business process analysis
- User interface

26

Requirements Analysis

- Create software model
- Reduce ambiguities

27

Requirements Specification

- Precisely state requirements
- Recording he specification
- Include functional and non-functional requirements

28

Requirements Validation

- Ensure you have the right requirements
- Ensure you have the requirements right

29

Functional requirements

- Describe an interaction between the software and a user, another system, a database, etc.
- There is typically a set of inputs, an operation, or a set of outputs

30

Non-functional requirements

- Do not specify software functionality
- Specify restrictions on some operation or thing
- Must be specific, quantifiable, and testable

31

Sources of requirements

- Stakeholders
- Existing systems
- Policy and procedure manuals
- Forms used in existing systems
- System manuals
- Issue logs
- Laws
- Rules
- Standards

32

Requirements artifacts

- Requirement Reports
- Problem Identification and Definition Document (PID)
- Top-Level Requirements (TLR) Document
- Software Requirements Specification (SRS)
- Use Cases and Scenarios
- User Stories and Scenarios
- Analysis Models

33

Structured Interviews

- Questions are pre-determined
- Adapt the questions based on responses

34

Task-based Interviews

- Interview has no pre-determined questions, only a task to perform
- Give the user a common problem to step through
- Ask questions while the user describes the steps
- The goal is to form a model of the user's thought process

35

Open Interviews

- There are no predefined questions or agenda
- Open discussion about what the client/user wants from the software

36

Observation

- "Walking around"
- Watch what users are doing, and how they are doing it
- Good for workflow analysis (capturing who does what and when)
- Good when replacing existing systems of automating manual tasks

37

Document Analysis

- Look at existing business documents to glean business processes
- Good when replacing paper processes

38

Rapid Prototyping

- Create a prototype (an initial version of the software available early in the development process)
- Often a throw-away (it is scrapped after gathering the requirements)
- Helps to verify the requirements
- Effective for developing user interfaces
- Can reveal inconsistencies in written requirements

39

Problem Identification and Definition Document (PID)

- Very high-level document
- Identifies the business value of the system
- Lists the high-level functionalities

1.) Name the project
2.) Identify the project sponsor(s)
3.) Identify the business need
4.) Identify user roles and high level functionalities
5.) Identify the expected value (feasibility analysis)
6.) Identify an special issues
7.) Glossary of Terms
8.) Priority List

40

Software Requirements Specification (SRS)

- IEEE Standard for software specifications
- Contains an overall description and specific requirements of the software

41

Software Architecture

The structure or structures of a system, which comprise software components, the externally visible requirements of those components, and the relationships among them.

42

Application Layers

Used to separate the areas of concern in an application.

43

Client/Server Architecture

Segregates the system into two applications, where the client makes requests to the server.

44

Component-based Architecture

Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

45

Layered Architecture

Partitions the concerns of the application into stacked groups (layers).

46

N-tiered Architecture

Segregates the functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.

47

Draw an architectural analysis model

...

48

Draw use case diagrams

...

49

Draw a data model using a class diagrm

...

50

Draw a functional model (high and low level) using a sequence diagram

...

51

Draw a behavioral model using state-machine diagrams

...

52

Draw a web application archetype

...

53

Draw a mobile application archetype

...

54

Draw a rich client application archetype

...

55

Coupling

The degree to which software components are interconnected

56

Cohesion

The degree to which elements of a group belong together.

57

Data Coupling

The interface between the units is a parameter list and all parameters are needed.

58

Stamp Coupling

The interface between the units is a parameter, which is some data structure containing fields but not all fields are needed.

59

Control Coupling

The interface between the units is data (e.g., flags and switches) that influences the internal logic of the unit.

60

Functional Cohesion

The elements of the program unit are grouped because they all contribute to a single, well-defined task.

61

Sequential Cohesion

The elements of the program unit are grouped because the output of one part is the input into another part.

62

Communicational Cohesion

The elements of the program unit are grouped together because they operate on the same data. It may be possible that the parts are performing more than one function.

63

Procedural Cohesion

The elements of the program unit are grouped together because they always follow a certain sequence of execution.

64

Single Responsibility Principle (SRP)

A class should have one, and only one, reason to change.

65

Open Closed Principle (OCP)

You should be able to extend a class' behavior without modifying it.

66

Liskov Substitution Principle (LSP)

Derived classes must be substitutable for their base classes.

67

Interface Segregation Principle (ISP)

Make fine grained interfaces that are client specific.

68

Dependency Inversion Principle (DIP)

Depend on abstractions, not on concretions.

69

Singleton

Creational design pattern in which there is exactly one instance of a class.

70

Adapter

Structural design pattern that solves the problem of using a different protocol/interface between interacting components.

- Write the application against abstract version of the external class.
- Introduce a subclass that aggregates the external class
- The client interacts with the Adapter, who rewrites it for the required class.

71

Strategy

A behavioral design pattern that essentially allows the definition of a family of algorithms, which are all interchangeable depending upon the client that uses them.

72

Unit Testing

The process used by developers to identify and fix defects in the program units.

73

Arrange

Setting up the environment, making sure all preconditions are met, selecting the input data, and determining the expected result.

74

Act

Applying the input data to the unit.

75

Assert

Comparing the actual result to the expected result.

76

Test class using MSTest

[TestClass]
public class ABankAccount

[TestMethod]
ShouldSetBalanceAndAnnualInterestRateWhenConstructed ( )

// Arrange, Act
var sut = new BankAccount (100.0m, 0.1m);

// Assert
Assert.AreEqual (100.0m, sut.Balance);
Assert.AreEqual (0.1m, sut.AnnualInterestRate);

77

Equivalence Partitioning

Divides input values into equivalent groups; used to limit the number of test cases to something "reasonable."

78

Statement Coverage

Ensures all statements in the unit are executed at least once by at least one test case.

79

Branch Coverage

Ensures all branches in the unit are executed at lease once by at least one test case.

80

All-path Coverage

Ensures that all path combinations in the unit are executed.

81

Describe the process of conducting a formal code review

1.) Readiness
- The author of the unit ensures that the unit is ready for review
2.) Preparation
- Before the meeting, each reviewer carefully review the code.
3.) Examination
- The author gives an overview of the logic, computation, and dependencies used in the code.
4.) Rework
- At the end of the meeting, the record-keeper produces a summary of the meeting.
5.) Validation
- The CRs are independently validated by the moderator or another person designated for that purpose
6.) Exit
- The review process is complete.

82

Create a system test case

...