Software Engineering Exam 1

Get Started. It's Free
or sign up with your email address
Software Engineering Exam 1 by Mind Map: Software Engineering Exam 1

1. Some General Process Models

1.1. Waterfall Model

1.1.1. -Highly Structured and Plan Driven -Each phase must be complete before the next one can begin - Once phase is complete it can be revisited -Suited for: Embedded systems, Critical systems, and Large Software systems

1.2. Integration and Configuration

1.2.1. - This is reused based software development - Pros: Reduction in development time, Generally faster delivery of software, Software reuse is good software engineering practice - Cons: Tailoring process may be restricted by the features of existing components, Client may lose control of the project, as requirements are modified to suit existing components

1.3. Incremental Model

1.3.1. - Develops Software as Improved Versions - After each version, feedback is used to influence refined specifications and further development - Customer receives an early experience of the system being developed - Used in Agile Software approaches

2. Types of Software Systems

2.1. Stand alone applications

2.2. Interactive transaction based

2.3. Embedded control systems

2.4. System for modeling and simulation

2.5. Data collection and analysis system

2.6. Entertainment system

2.7. Batch processing

2.8. System of systems

2.9. Critical systems

3. Emerging software types

3.1. WebApps

3.2. Mobile Applications

3.3. Cloud computing

4. Ethical Considerations

4.1. Confidentiality

4.2. Competence

4.3. Reliability and Dependability of Software

4.4. Software Security

4.5. Respect for Intellectual Property

4.6. Computer Misuse

5. Four basic process activities

5.1. Specification

5.1.1. Also called Requirements Engineering

5.1.2. Defines constraints of what the software should do

5.1.3. Activities

5.1.3.1. Requirements elicitation - what is required of the system

5.1.3.2. Requirements specification - requirements are documented and separated into user or system requirements

5.1.3.2.1. User requirement

5.1.3.2.2. System requirement

5.1.3.3. Requirements validation - checking the validity of requirements

5.1.3.3.1. Requirements checking

5.1.3.3.2. Techniques

5.1.3.3.3. Review checks

5.1.3.4. Requirements change - requirements are always changing after installation

5.1.3.4.1. Changing requirements

5.1.3.4.2. Requirements management

5.1.3.4.3. Requirements evoluton

5.1.4. Agile development - not a separate or isolated phase

5.2. Development

5.2.1. Design

5.2.1.1. Activities

5.2.1.1.1. Architectural design

5.2.1.1.2. Database design

5.2.1.1.3. Interface design

5.2.1.1.4. Component selection

5.2.2. Implementation

5.3. Testing and Validation

5.3.1. - Synonym: Verification and Validation

5.3.2. - Used to show that: System conforms to its specifications, System meets customer requirements - Achieved through: System testing, inspection, reviews - System testing includes: Selecting test-cases to mimic the desired operating environment of the system, and Executing the system and evaluating performance

5.4. Evolution

5.4.1. - Often referred to as maintenance - Addresses the need for software to change with time: to meet changing requirements , to enhance system functionality, and to correct system flaws

5.4.1.1. Translates design to program

5.4.1.1.1. - Configures existing system or creates new one - Includes debugging

6. The Changing Development Environment

6.1. Reasons for Change

6.1.1. Business changes

6.1.2. New technologies = new possibilities for improving implementations

6.1.3. Change of platforms

6.2. Lower the cost of change

6.2.1. Anticipate Change

6.2.1.1. Prototyping

6.2.1.1.1. Using

6.2.1.1.2. Benefits

6.2.1.1.3. Development

6.2.1.1.4. Throw-Away Prototypes

6.2.2. Change Tolerant system

6.2.2.1. Incremental Delivery

6.2.2.1.1. Development

6.2.2.1.2. Delivery

7. Requirements Engineering Process

7.1. - The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. - However, there are a number of generic activities common to all processes: Requirements Elicitation, Requirements Analysis, Requirements Validation, Requirements management - In practice, RE is an iterative activity in which these processes are interleaved

7.2. Requirements Elicitation

7.2.1. Requirements discovery

7.2.1.1. - Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.

7.2.2. Requirements classification and organisation

7.2.2.1. - Groups related requirements and organises them into coherent clusters

7.2.3. Prioritization and negotiation

7.2.3.1. - Prioritizing requirements and resolving requirements conflicts

7.2.4. Requirements specification

7.2.4.1. - Requirements are documented and input into the next round of the spiral -The process of writing down the user and system requirements in a requirements document - User requirements have to be understandable to end-users and customers who do not have a technical background - System requirements are more detailed requirements and may include more technical information - The requirements may be part of a contract for the system development

7.3. Problems of Requirements Elicitation

7.3.1. - Stakeholders don’t know what they really want - Stakeholders express requirements in their own terms - Different stakeholders may have conflicting requirements - Organizational and political factors may influence the system requirements - The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.

7.4. Techniques used to Elicit Requirements

7.4.1. Interviews

7.4.1.1. Types of Interviews

7.4.1.1.1. - Closed interviews based on pre-determined list of questions - Open interviews where various issues are explored with stakeholders

7.4.1.2. Effective interviewing

7.4.1.2.1. - Be open-minded, avoid pre-conceived ideas about the requirements - Listen to stakeholders. - Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system

7.4.1.3. Problems with interviews

7.4.1.3.1. - Application specialists may use language to describe their work that isn’t easy for the requirements engineer to understand - Interviews are not good for understanding domain requirements: Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating

7.4.2. JAD (Joint Application Design) sessions

7.4.3. Questionnaires

7.4.4. Document Analysis

7.4.5. Observation

7.5. Guidelines for Writing Requirements

7.5.1. - Invent a standard format and use it for all requirements - Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. - Use text highlighting to identify key parts of the requirement. - Avoid the use of computer jargon - Include an explanation (rationale) of why a requirement is necessary

7.6. Modeling Requirements

7.6.1. Use case

7.6.1.1. - Understand and elaborate on user requirements -Communicate with user

7.6.1.2. Use case model

7.6.1.2.1. - Identifying use cases - Identifying steps in each use case - Identifying sub-steps - Confirmation

7.6.1.2.2. Use case diagram

7.6.1.2.3. Lack of identifying

8. Cost of software

8.1. Evolution: 45%

8.2. Development: 33%

8.3. Testing: 22%

9. Stages of Testing

9.1. Acceptance Testing

9.1.1. - Testing with customer data to check that the system meets the customer’s needs

9.2. System Testing

9.2.1. - Testing of the system as a whole

9.3. Component Testing

9.3.1. - Individual components are tested independently - Components may be functions or objects or coherent groupings of these entities

9.4. Alpha Testing

9.4.1. - Simulate the environment

9.5. Beta Testing

9.5.1. - Real data and customers

10. Process Improvement

10.1. Approaches to Improvement

10.1.1. Process Maturity

10.1.1.1. - reflects the extent to which good technical and management practice has been adopted in organizational software development processes - focuses on improving process and project management and introducing good software engineering practice

10.1.2. Agile Approach

10.1.2.1. - The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing customer requirements - focuses on iterative development and the reduction of overheads in the software process

10.2. Process Improvement Activities

10.2.1. Process Measurement

10.2.1.1. - measure one or more attributes of the software process or product - measurements form a baseline that helps you decide if process improvements have been effective

10.2.2. Process Analysis

10.2.2.1. - current process in assessed - process weaknesses and bottlenecks are identified - Process models (sometimes called process maps) that describe the process may be developed

10.2.3. Process Change

10.2.3.1. - Process changes are proposed to address some of the identified process weaknesses - Apply changes and resume process cycle to collect data about the effectiveness of the changes

10.3. Process Measurement

10.3.1. - Wherever possible, quantitative process data should be collected - Process measurements should be used to assess process improvements

10.4. Process Metrics

10.4.1. - Time taken for process activities to be completed - Resources required for processes or activities - Number of occurrences of a particular event

11. The SEI Capability Maturity Model

11.1. - Used to assess software process maturity of company or group

11.2. Levels Identified

11.2.1. Initial

11.2.1.1. - Overall goals of the process are clearly stated and satisfied - Process is Essentially uncontrolled

11.2.2. Managed

11.2.2.1. - Product management procedures defined and used including: Documentation and Process Monitoring

11.2.3. Defined

11.2.3.1. - Standardized process management procedures and strategies are defined and used

11.2.4. Quantitatively Managed

11.2.4.1. - Quality management strategies defined and used involving measurement of the processes

11.2.5. Optimizing

11.2.5.1. - Process improvement strategies defined and used

12. System Modeling

12.1. -Process of developing abstract models of a system -Helps clarify the functionality of the system and the communication with the customer

12.2. Perspectives for System Models

12.2.1. External Perspective

12.2.2. Interaction Perspective

12.2.3. Structural Perspective

12.2.4. Behavioral Perspective

12.3. Types of Models

12.3.1. Context Models

12.3.1.1. Used to show illustrate the operational context of a system - what lies outside the system boundaries

12.3.2. Interaction Models

12.3.2.1. -Models User Interaction, system-to-system interaction, and component interaction -UML diagrams used: Use case, Sequence Diagrams

12.3.2.1.1. Use Case Models

12.3.3. Structural Models

12.3.3.1. -Display the organization of a system in terms of the components that make up the system -May be static models, which show the structure of the system model -May be dynamic models which show the organization of the system

12.3.4. Behavioral Models

12.3.4.1. - Behavioral models are models of the dynamic behavior of a system as it is executing - Two Types: 1) Data - some data arrives that has to be processed by the system 2) Events -Some event happens that triggers system processing. Events may have associated data, although this is not always the case

12.3.4.2. Data-Driven Modeling

12.3.4.2.1. - Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing. - Data-Driven models show the sequence of actions involved in processing input data and generating an associated output - They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system

12.3.4.3. Event-Driven Modeling

12.3.4.3.1. - Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as 'receiver off hook' by generating a dial tone. - Event-driven modeling shows how a system responds to external and internal events. - It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another

12.3.4.4. State Machine Models

12.3.4.4.1. - These model the behavior of the system in response to external and internal events - They show the system's responses to stimuli so are often used for modeling real-time systems. - State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another - Statecharts are an integral part of the UML and are used to represent state machine models

12.3.5. Model-Driven Engineering

12.4. UML diagrams for system modeling

12.4.1. Activity Diagrams

12.4.1.1. Shows the activities involved in a process or in data processing

12.4.2. Use-Case diagrams

12.4.2.1. Shows the interactions between a system and it's users

12.4.3. Sequence Diagrams

12.4.3.1. Shows interaction between actors and the system and between system components

12.4.4. Class Diagrams

12.4.4.1. Shows the object classes in the system and the associations between these classes

12.4.5. State Diagrams

12.4.5.1. Shows how the system reacts to internal and external events