ESE Intro

• Design, Implementation and Testing are iterative activities
  • The implementation does not 'implement the design' but rather the design document documents the implementation
• System tests reflect the requirements specifiaction
• Testing and implementation go hand-in-hand
  • Ideally, test case specification procedes design and implementationn

The process of changing a system after it has been deployed

Corrective maintenance: identifying and repairing defects

Adaptive maintenance: adapting the existing solution to new platforms

Perfective maintenance: implementing new requirements

• Configuratio nand version management
• Reengineneeringn (redesign and refactor)
• Updating all analysis, design and user documentation

Repeatable, automated tests enable evolution and refactoring

Software Engineering must cope with the fact that real software projects are long-lived, and they evolve considerable over their lifetime.

Principle = general statement describing desirable properties

Method = General guidelines governing some activity

Technique = more technical and mechanical than method

Methodology = package of methods and techniques packaged

• Programming is a part of Software Engineering. Software Engineering is about applying engineering principles to create software. 

• SE must cope with the fact that real software are long-lived, and they evolve considerable over their lifetime.

Because these processes run in parallel. It’s unrealistic for example to collect all requirements before even starting to design the project.

• Analysis: Process of specifying what a system will do - The result of analysis is a specification document. WHAT

• Design: Process of specifying how the specified system behaviour will be realised from software components - The results are architecture and detailed design documents. HOW

• Conclusion: Design is way more specific than analysis

Because you won’t get it right the first time. The goal is to have a running program and then incrementally add functionality.

Because good software can be used over a long period of time. But what’s necessary is maintenance which accounts for 70% of total costs.

Pro: Succesful in the construction of large, complex software systems.

Con: Steep learning curve, programs are slower and require more lines of code

It looks cleaner. Gives the illusion that a project is proceeding according to a precise plan.

• By iteration and testing

• CRC cards -> see next lecture

They are iterative activities so there is no clear distinction in-between. However, analysis is more about elaboration and design is about construction.

• Ideally after test specification.
• Design, implementation and testing are iterative activities

State of the art of developing quality software on time and within budget

Multi person construction of multi version software

Software engineering is different from other engineering disciplines (not constrained by physical law)

(Engineering practices cover not only technological aspects of the products being built, but also such diverse aspects such as planning, process management, and quality standards.

Requirements Collection: Establish customer's needs

Analysis: Model annd specify the requirements ('what')

Design: Model and specify a solution ('how')

Implementation: Construct a solution in a software

Testing: Validate the solution against the requirements

Maintenance: Repair defects and adapt the solution to new requirements

(these are ongoing activties not sequential phases)

- Because requirements must be frozen too early in the life cycle

- Because requirements are validated too late

--------------------------------

1. Iteration always occurs
2. Difficult to state all requirements explicitly at the beginning of the project
3. There won't be a working version of the software until late in the project

(Early prototyping helps to alleviate 2 and 3)

New requirements can be introduced at any point in the project. Implementation of prototypes may start before detailed design to explore requirements. Testing typically starts as implementation starts.

Plan to iterate your analysis, design and implementation

(You won't get it right the first time, so integrate, validate, test)

(You should only use iterative development on projects that you want to succeed)

With each iteration the system incrementally grows and evolves

Keyword: Iterative and incremental spiral lifecycle

If possible always have a running version of the system, even if most functionality is yet to be implemented

Integrate new functionality as soon as possible

Validate incremental versions against user requirements

Framework for an iterative development lifecycle proposed by Rational Software.

User requirements are often expressed informally (features, usage scenarios)

With use cases and scenarios one can bridge the gap between the user domain and the technical domain

Although requirements may be documented in written form, they may be incomplete, ambiguous, or even incorrect.

Validation is needed troughout the software cycle to cope with changing requirements

• Build constant feedback into your project plan
• Plan for change
• Early prototyping can help clarify requirements

Analysis is the process of specifying what a system will do

Provide clear understanding of what the system is about and what its underlying concepts are

The result of analysis is a specification document

Models of the system which describe:

• Classes of objects that exists inn the system
  • responsibilitiies of those classes
• Relationships between those classes
• Use cases and scenarios describing
  • Operations that can be performed on the system
  • Allowable sequences of those operations

tools to models domain concepts in code --> bridge gap between the application and technical domains

A prototype is s software program developed to test, explore or validate a hypothesis (i.e. to reduce risks)

Also known as a throwaway prototype, is intended to validate requirements or explore design choices.

• UI Prototype - validate user requirements
• Rapid prototype - validate functional requirements
• Experimental prototype - validate technical feasibility