Announcements/Assignments Beginning on Friday, this class will meet in Architecture Hall, room 127 (this is on the East side of the building) I asked you to read Ghezzi Chapter 1 for today Be sure to attend class Friday to discuss the project and do team selection

This Class

Problems of Scale in Engineering Built by one person Requires minimal to no planning Design and implementation blend Simple tools & construction Faults have small consequences Teams with different roles Scheduling and dependencies Models & abstraction Specialized languages and tools Formal communication Large impact of changes and faults Domain knowledge

Problems of Scale in Engineering Built by one person Requires minimal to no planning Design and implementation blend Simple tools & construction Faults have small consequences Teams with different roles Scheduling and dependencies Models & abstraction Specialized languages and tools Formal communication Large impact of changes and faults Domain knowledge These same problems of scale apply when transitioning from coding to software engineering

Scaling Up Requires Systematic Engineering Processes of Many Types Requirements elicitation and analysis Requirements specification Requirements verification Architectural design Lower-level design Coding and unit testing Integration testing System testing Evolution and maintenance

What This Class is About Building complex software systems Interacting with other stakeholders Building the right system (getting system requirements right) Creating extensible architectures and system designs Making sure you’ve built the system right (verification and validation) It is only minimally about “coding”

Goal Begin to prepare you for: Large-scale software development including group dynamics, management Working with other people coordination of effort requirements elicitation and specification design techniques software processes quality assurance approaches sophisticated tools

Software Lifecycle and Process Models

Software Lifecycle & Process Models Abstract representations of software development processes Provide guidance for project management What major tasks should be tackled next? How long should we spend on this task? What kind of progress has been made? Provide guidance for project staff Am I doing the right thing? Am I on schedule?

“Monolithic” Processes

Problems The assumption is that an informal understanding of requirements prior to development is enough This assumption almost never holds; requirements change as our understanding of the system grows, and informality leads to errors Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Limiting interaction makes it difficult to correctly understand requirements in a timely manner

“Staged” Processes

Advantages Reduce risks by improving visibility Allow project changes as the project progresses based on feedback from the customer based on domain knowledge gained

Software Process Models Waterfall model Linear, distinct phases of specification and development Reuse-based model The system is assembled from existing components Incremental model The system is built in distinct increments Agile / XP model Takes the incremental model to extremes Formal systems model A mathematical system model is formally transformed to an implementation

Simple Waterfall Process Model Requirements Analysis and Specification Design and Specification Coding and Unit Testing Integration and System Testing Delivery and Maintenance

Historical Notes The waterfall model is based on development models used in manufacturing. In such cases, changes in product and requirements are prohibitively expensive, so the model works. Also known as a “Big Design up Front” model First known presentation, 1956, Herbert Benington at a Symposium on programming methods First formalization, Winston Royce, as an example of a “flawed” model.

Waterfall Model Phases Requirements analysis and specification Often preceded by feasibility or “market” study Identify “what” must be built, including functionality and constraints Document requirements in user terms and in terms appropriate for designers/developers Requires interaction with customers, and domain knowledge Various models for expressing requirements are available

Waterfall Model Phases Design and specification Specifies the “how”, not the “what” Often split into architectural and detailed design Architectural design expresses overall system organization, decomposes system into modules Detailed design provides further details Considers reuse Various models for expressing designs are available

Waterfall Model Phases Coding and unit testing System is coded to meet the design specification Unit testing is applied to individual modules, usually by developers

Waterfall Model Phases Integration and system testing Integration testing tests modules as they are put together, using stubs and drivers System testing tests the entire system, including hardware and software (perhaps with simulators) These phases may be conducted by developers and/or dedicated test engineers

Waterfall Model Phases Delivery and maintenance System is packaged for delivery; this includes all code, documentation, and other deliverables System goes into “maintenance”, where it continues to be perfected, adapted, and corrected When systems are evolving (as opposed to just being “corrected”), maintenance means revisiting the requirements, design, implementation and testing phases again.

Waterfall Model Advantages Simple, disciplined, structured Time spent well early in the project increases the chance it will succeed and decreases some risks Emphasizes documentation, important in long-term larger projects Requirements Analysis and Specification Design and Specification Coding and Unit Testing Integration and System Testing Delivery and Maintenance

Waterfall Model Disadvantages Each phase must be complete before the next can be begun Difficult to accommodate change after the process is underway Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements The model is appropriate only when the requirements are well-understood Requirements Analysis and Specification Design and Specification Coding and Unit Testing Integration and System Testing Delivery and Maintenance

Waterfall Model with “Feedback” Requirements Analysis and Specification Design and Specification Coding and Unit Testing Integration and System Testing Delivery and Maintenance

Reuse-Oriented Development Model Based on systematic reuse where systems are integrated from existing components Process stages Component analysis Requirements modification System design with reuse Development and integration

Reuse-Oriented Development Model Advantages Can save time and effort Builds on reliability of existing systems Drawbacks Can lead to unfortunate compromises Building with future reuse in mind can slow effort, as we try to build things that are more general

Incremental Development Model (a.k.a. Feature Driven Development) Development/delivery is broken into increments Each increment delivers part of the required functionality Identifying self-contained functional units (“features”) that may be delivered to customers is crucial

Incremental Development Model User requirements are prioritized Highest priority requirements are included in early increments Once development of an increment is started, the requirements are frozen Requirements for later increments can still evolve some

Incremental Development Model Advantages Customer value is delivered with each increment so system functionality is available earlier Early increments act as prototypes Higher priority system services tend to receive the most testing (not necessarily a bad thing for non-critical systems) Disadvantages Expectation that most requirements can be known early in the process

“Agile” Development Models Development and delivery of very small increments of functionality Teams of 5-10 spend 2-4 weeks per increment Needs to begin with a relatively clear view of requirements, and a sound architecture/design Relies (mostly) on well validated principles Pair programming (reviews) Revisiting and refactoring (iteration and refinements) Test first (test before programming)

Agile Development Models Advantages Provides functionality quickly Allows fast response to changing requirements Allows early and frequent feedback Early functionality gets more testing Disadvantages Focuses on working software at the expense of documentation Development can get off track if customer is not clear about ultimate goals Future system maintainability depends on how well requirements/architecture can be expressed initially

Formal Systems Development Model Based on the transformation of a mathematical specification through different representations to an executable program Transformations are “correctness-preserving” straightforward to show that the program conforms to its specification

Formal Transformations Small increments

Formal Systems Development Advantages Produces highly reliable systems Disadvantages Requires specialized skills and training Difficult to formally specify some aspects of systems Applicability Critical systems (or subsystems), especially those where a safety or security case must be made before the system is put into operation

Software Process Models Waterfall model Linear, distinct phases of specification and development Reuse-based model The system is assembled from existing components Incremental model The system is built in distinct increments Agile / XP model Takes the incremental model to extremes Formal systems model A mathematical system model is formally transformed to an implementation