ESE Intro

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

An evolutionary prototype is intended to evolve in steps into a finished product

Iteratively grow the application, redesigning and refactoring along the way

(First do it, then do it right, then do it fast)

Specifing how the specified behaviour (analysis) will be realized from software components. 

The results are architecture and detailed design documents

Design is an iterative process, proceeding in parallel with implementation

How system operations are implemented by interacting 

How classes refer to one another and how they are related by inheritance

Attributes and operations associated to classes

Organization that design systems are constrained to produce designs that are copies of the communication structures of these organizations.

If your software team splits responsibilities in a certain way, you can expect that the software will also be structured in the same way.

The activity of constructing a software solution to the customer's requirements

Testing is the process of validating that the solution meets the requirements.

Fully documented and validated solution

• 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