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