Review 20 March

Announcements EA here today Let me know if you are looking for a job or summer internship John Smith Current Events: John BackusJohn Backus

(Software) Engineering Turning ideas into reality Creating something useful from other things using science and math

The right software, delivered defect free, on time and on cost, every time. Carnegie Mellon Software Engineering Institute Software Engineering Objective

The 4 P’s of Software Engineering Product: what is produced People: those doing it Project: the doing of it Process: the manner in which it is done

Project: the doing of it Quality Risk Management

Project: the doing of it Quality Risk Management

Expectations of Software Engineering (Watts Humphrey)Watts Humphrey 1.Predetermine quantitative quality goals 2.Accumulate data for use in later projects 3.Keep all work visible 4.Design, program and test only against requirements 5.Measure and achieve quality goals

Quality Management Principles Customer focus Leadership Involvement of people Process approach System approach to management Continual improvement Factual approach to decision making

Project: the doing of it Quality Risk Management

Risks 80% of software projects fail Two types of risk Avoidable Unavoidable

Should we eliminate risk? Take calculated risks. That is quite different from being rash. (Patton) Great deeds are usually wrought at great risks. (Herodotus) Great deeds are usually wrought at great risks. (Nehru) No risk => no challenge

Risk Management 1. Identification 2. Mitigation plan 3. Prioritization 4. Retirement

Sources of Risk 1. Top management commitment 2. User commitment 3. Misunderstood requirements 4. Inadequate user involvement 5. Mismanaged user expectations 6. Scope creep 7. Lack of knowledge or skill Keil et al, “A Framework for Identifying Software Project Risks,” CACM 41:11, November 1998.

Technical Risks New features New technology Developer learning curve Changes that may affect old code Dependencies Complexity Bug history Late changes Rushed work Tired programmers Slipped in “pet” features Unbudgeted items

Project: the doing of it Quality Risk Management

What can be controlled? Cost Number of people Hours worked Hardware and software used Capability Function that you ship Quality Procedures that increase cost and quality Testing Delivery Dates

Project Management Tasks Management process Define and drive Schedule Staffing plan Risk Management Development process Document identification

Management Process: Organization Needed to control communications cost Channel of communications costs about 2 hours per week Optimal number 3-7 Organization structures Hierarchical Peer Requires leader of team or aspects Subteam Requires gatekeeper Matrix

Schedule: Scheduling Steps and Tools Put together minimal solution Primary requirements Start with external commitments Product descriptions Customer milestones Introduce internal milestones Work breakdown structure Product flow PERT chart, Gantt chart Focus on the risks Add next level of features where possible Secondary requirements

Risk Management: Reviews and Inspections Why? Developer can’t correct unseen errors More eyes to catch problems Earlier is cheaper Integration fix typically 3-10 times the cost at design Review often by someone at a higher level completed work Inspection (formalized process; Fagin 76) peer review work in progress

Process: the manner in which it is done Differ by how often you do the steps Points on the spectrum Differences in overhead Three fundamental models Waterfall Spiral Iterative Two widely used models Rational Unified Process (a.k.a. Unified Software Development Process) Extreme Programming

Rational Unified Process Matrix ElaborationInceptionConstructionTransition Requirements Analysis Design Implementation Test Phases Workflows

Agile Methodologies Keep only those rules and processes that help Antidote to bureaucracy Key characteristics Adaptive People-oriented

Extreme Programming Complete development process First code drop is 2-3 weeks after start Customer a part of the development team Iterative development to the max Derive requirements with customer through hands-on experimentation

XP Value System Communication Focus on people, not documentation Simplicity Of process and code Feedback Mechanism to make useful progress Courage To trust in people

Extreme Programming Project

XP Bills of Rights Developer has a right to Clear requirements and priorities Determine how long a requirement will take to implement Revise estimates Always produce quality code Customer has a right to An overall plan See progress in a running system Change requirements and priorities Be informed of changes to schedule and have input as to how to adapt Cancel in the middle and still have something to show for the investment

Egoless Programming Weinberg 1971, The Psychology of Computer Programming During the “cowboy” era Observed that programmers needed to be team players Accept inspections and reviews Open to corrections and critiques Ten Commandments (Lamont Adams) Ten Commandments But pride of ownership is critical to quality

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

Requirements Analysis To build something, we first must understand what it is we’re building Establish expectations Understandable by both the client and the developer

Sources of requirements People Broad range of stakeholders Conflicting requirements Wants and needs Helping the customer articulate the requirements: use cases Hardware constraints Laws of physics and nature Social responsibility

Use Cases A statement of the functionality users expect and need, organized by functional units  Functional units are any natural division  Relationships between user roles and use cases  User activities, decisions, and objects involved

Requirement requirements A requirement must be written expressed precisely expressed as what, not how prioritized testable The set of requirements must be… consistent complete

Types of Requirements Functional: services that the application must provide Performance: speed, capacity, memory Reliability and availability: failure rates Error handling: how to handle Interface: user and program Constraints: systems or tolerances (Inverse requirements: what it won’t do )

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

What is an Architecture? Complete and detailed specification of the user interface (Brooks, The Mythical Man-Month) Architecture: what happens; implementation: how it is made to happen (Blauuw)

The UI Iceberg Visuals InteractionTechniques Object Model Feel 30% Look 10% The things you use 60%  Toolkits and style guides help with look and feel, the tip of the usability iceberg.  Real usability gains come from system and application objects perceived by users.

Fundamental Concepts What the user needs to do The order that he does it Is it natural? How much does he have to remember?

Good Screen Design Consistency: use of pull-downs vs. entry Starting in the upper left corner: first thing to fill in Simple navigation Grouping and alignment Keep related issues together Captions for clarity

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

Modeling Based on abstraction Looking only at relevant information Hiding details Create multiple views As orthogonal as possible Each view has information that is unique Each view has information that appears in other views Common information is consistent

Modeling Languages and Processes Language: syntax, usually graphical, used to express design Process: steps to take to create a design Many processes, not a lot of agreement General consensus has built around UML as a language

“Software Architecture” Architecture is the external view Software “external view” is highest level design We’ll refer to it as “system design” Not consistent in industry or literature

System Design Goals Correctness Extensibility: adding new features Tradeoff of generality and time How might it be extended? Changeability: requirements changes Simplicity: ease of understanding and implementing Efficiency: speed and size

System Design Characteristics Cohesion degree to which communication takes place within the module Coupling degree to which communication takes place between modules Min-max problem: minimize coupling while maximizing cohesion

System Design Patterns Model-View-Controller Data flow systems Pipes and filters Batch sequential Independent components Client-server Parallel communicating processes Event systems Virtual machines Interpreters Rule-based systems Repositories Databases Hypertext systems Layered architectures

Detailed Design Build on well understood patterns from the system design Goal is to prepare the project for implementation Includes System design decomposition (modules, processes, data) Detailed module definitions Detailed data definitions Design decisions

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

Implementation Items Start small Appropriate level of documentation Error handling

Tools Version Management Build Systems Integrated Development Environments

Using XML Design goals Separation of changeable decisions Need for multiple forms for the same data XML a standard implementation option, but not the only one Provides tools (may or may not be beneficial)

Software Engineering: Elaborated Steps Concept Requirements Architecture Design Implementation Integration System test Maintenance

Midterm Reminders Virtual in-class Posted on web at 12:25 “Postmarked” by 1:50 Open notes, books, computers