1. Coping with change
   1. Change is inevitable in all large software projects.
   2. Two related approaches may be used to reduce the costs of rework:
      1. Change anticipation: Where ithe software process includes activities that can anticipate or predict possible changes before significant rework is required.
      2. Change tolerance: Where the process and software are designed so that changes can be easily made to the system.
   3. Two ways of coping with change and changing system requirements:
      1. System prototyping: where a version of the system or part of the system is developed quickly to check the customer's requirements and the feasibility of design decisions.
      2. Incremental delivery: Where system increments are delivered to the customer for comment and experimentation.
   4. Prototyping
      1. A software prototype can be used in a software development process to help anticipate changes that may be required:
         1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements.
         2. In the system design engineering process, a prototype can be used to explore software solutions and in the development of a used interface for the system.
   5. Incremental delivery
      1. Incremental delivery has a number of advantages
         1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments.
         2. Customers don't have to way until the entire system is delivered before the can gain value from it
         3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.
         4. As the highest priority services are delivered first and later increments then integrated, the most important system services receive the most testing.
      2. There are problems with incremental delivery.
2. Process Improvement
   1. Two quite different approaches improvement and change are used:
      1. The process maturity approach
         1. Which has focused on improving process and project management and introducing good software engineering practice into an organizarion
         2. The level of process reflects the extent to which good technical and management practice has been adopted in organizational software.
         3. The primary goals of this approach are improved product quality and process predictability.
      2. The agile approach
         1. Which has focused on iterative developmen and the reduction of overheads in the software process.
         2. Are rapid delivery of functionality and responsiveness to changing customer requirements.
   2. The stages in this process are:
      1. Process measurement
         1. You measure one or more attributes of the software process or product.
         2. These measurements form a baseline that helps you decide if process improvements have been effective.
      2. Process analysis
         1. The current process is assessed, and process weaknesses and bottlenecks are identified.
         2. Process models (Process maps): that describe the process may be developed during this stages.
      3. Process change
         1. Process changes are proposed to address some of the identified process weaknesses.
   3. The levels in the process maturity model are:
      1. Initial: The foals associated with the process area are satisfied, and for all processes the scope of the work to be performed.
      2. Managed: the goals associated with the process area are met, and organizational policies are in place that define when each process should be used.
      3. Defined: this level focuses on organizational standardization and deployment of processes.
      4. Quantitatively managed: there is an organizational responsibility to use statistical and other quantitative methods to control subprocesses.
      5. Optimizing: the organization must use the process and product measurements to drive process improvements.
3. Process Activities
   1. Software specification
      1. Activities
         1. Requirements elicitation and analysis
            1. This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on.
            2. These help you understand the system to be specified.
         2. Requirements specification
            1. Is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements.
         3. Requirements validation
            1. This activity checks the requirements for realism, consistency, and completeness.
            2. Errors in the requirements document are inevitably discovered
   2. Software design and implementation
      1. Activities:
         1. Architectural design
            1. Where you identify the overall structure of the system/
         2. Database design
            1. Where you design the system data structures and how these are to be represented in a database.
         3. Interface design
            1. Where you define the interfaces between system components
            2. This interface specification must be unambiguous.
         4. Component selection and design
            1. Where you search for reusable components and, if no suitable components are available, design new software components.
   3. Software validation
      1. Subtopic 1
         1. Component testing
         2. System testing
         3. Customer testing
   4. Software evolution
4. Software Process Models
   1. The general process models that I cover here are:
      1. The Waterfall Model
         1. This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, and testing.
         2. Activities:
            1. Requirements definition
            2. The system's services, constraints, and goals are established by consultation with system users.
            3. They are then defined in detail and serve as a system specification
            4. System and software design
            5. System design
            6. Process allocates the requirements to either hardware or software system.
            7. Software design
            8. Involves identifying and describing the fundamental software system abstractions and their relationships.
            9. Implementation and unit testing
            10. The software design is realized as a set of programs or program units.
            11. Unit testing involves verifying that each unit meets its specification.
            12. Integration and system testing
            13. The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met.
            14. After testing, the software system is delivered to the customer.
            15. Operation and maintenance
            16. This is the longest life - cycle phase.
            17. Maintenance involver correcting errors that were not discovered in earlier stages of the life cycle.
         3. During design, problems with requirements are identified. During Coding design problems are found, and so on.
         4. Types of system
            1. Embedded systems
            2. Where the software has to interface with hardware systems.
            3. Critical systems
            4. Where there is a need for extensive safety and security analysis of the software specification and design.
            5. The specification and design documents must be complete so that this analysis is possible.
            6. Safety related problems in the specification and design are usually very expensive to correct at the implementation stage.
            7. Large software systems
            8. That are the part of broader engineering systems developed by several partner companies.
      2. Incremental Development
         1. This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
         2. Is based on the idea of developing an initial implementation, getting feedback from users and others, and evolving the software through several versions until the required system has been developed.
         3. Major advantages over the waterfall model
            1. The cost of implementing requirements changes is reduced. The amount of analysis and documentation that has do be redone is significantly less than is required with the waterfall model.
            2. It's easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented.
            3. Early delivery and depolyment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process
         4. Two problems:
            1. The process is not visible. Managers need regular deliverables to measure progress.
            2. System structure tends to degrade as new increments are added. Regular change leads to messy code as new functionality is added in whatever way is possible.
      3. Integration and configuration
         1. approach relies on the availability of reusable components or systems. The system development process focused on configuring these components for use in a new setting and integrating them into a system.
         2. Three types of software components are frequently reused:
            1. Stand - alone application systems
            2. Collections of objects
            3. Web services
         3. The stages in this process are:
            1. Requirements specification: The initial requirements for the system are proposed.
            2. Software discovery and evaluation: given an outline of the software requirements, a search is made for components and systems that provide the functionality required.
            3. Requirements refinement: The requirements are refined using information about the reusable components and applications that have been discovered. Where modifications are impossible.
            4. Application system configuration: If an off-the-shelf application system that meets the requirements is a available.
            5. Component adaptation and integration: if there is no off-the-shelf system, individual reusable components may be modified and new components developed.
      4. RUP
         1. Is a flexible model that can be instantiated in different ways to create processes that resemble any of the general process models discussed here
   2. Is a simplified representtion od software process.
   3. These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development.
5. Four fundamental software engineering activities:
   1. Software Specification: the funcionality of the software and constraints on its operation must be defined.
   2. Software Development: the software to meet the specification must be produced.
   3. Software Validation: the software must be validated to ensure that it does what the customer wants.
   4. Software Evolution: the software must evolve to meet changing customer needs.