CS 3050 Software Engineering Methodologies

Methodology u Modeling language  Graphical notation used to express the design uProcess  Guidelines on what steps to take when developing software

Methodology Goals u Establish rules for applying techniques and notations u Establish heuristics for judging when the different stages are complete

Software Development Lifecycle (SDLC) u Describes each step in the process of developing an application u Sets the course and direction of the project

Software Development Lifecycle (SDLC) u Use case driven u Establish the desired behavior of the system u Architecture-centric u For conceptualizing, constructing, managing, and evolving the system under development

Software Development Lifecycle (SDLC) u Iterative u Managing a stream of executable releases u Incremental u Continuous integration of the system’s architecture to produce these releases. Each new release embodies incremental improvements over the other.

Waterfall Model uWaterfall Model  Regarded as the traditional model for Software development - though only described by Royce in 1970  Clearly defined and delineated steps with time- linear progression  Based on the argument that software development is an engineering discipline and can thus be described similarly to other engineering processes

Waterfall Model Requirements Analysis & Definition System & Software Design Implement- ation & Unit Testing Integration & System Testing

Requirements Analysis & Definition System & Software Design Implement- ation & Unit Testing Integration & System Testing Operation & Maintenance Software Lifecycle Based on Waterfall Model

Exploratory Programming uExploratory Programming Developed from early work in A.I. Used in situations where a specification cannot be elicited or is very unclear Similar to prototyping in that it iterates through a number of development cycles, but it does not attempt to develop a specification Validation and verification are impossible Tends to result in systems with poorly defined structure, little or no documentation Difficult to manage due to lack of definable milestones in development path

Prototyping uPrototyping Similar to exploratory programming in that it involves starting with the development of a program The aim of the developing prototypes is to elicit and clarify a software specification Once a specification is established, a more formal devlopment path is followed Currently very much in favour in industry, through RAD and DSDM.

Other Methodologies uFormal Transformation Used in the development of safety-critical software Define specification in formal notation (i.e. Z), thereby preserving all correctness properties Develop program from formal specification, proving all components of program through formal correctness proofs. Longer time-scale trade-off against higher level of reliability uSoftware Reuse Assembly of programs from components Widely-used for interface design, i.e. Visual Basic, Visual C++, X-Windows, Delphi, etc.

Managing Software Development uManaging Software Development Various process models are used Most common technique is “deliverables” Ongoing support for waterfall model is explicable in terms of the ease with which “document deliverables” can be generated at strategic points in the development cycle Formal transformation provides the most tightly manageable model Prototyping and Exploratory Programming are very difficult to manage in this way, since generating documents at each iteration is uneconomic Documentation constrains software reuse

Two “must-have” traits in your project Strong architectural Vision Well managed iterative and incremental development life cycle.

Strong Architectural Vision Well Defined Abstractions and Interfaces Clear boundaries between implementation and interfaces Simple architecture: Reuse, Super Classes Given: Good architectures tend to be object-oriented!

Development Life-Cycle Two ways to “drop the ball”: Dictatorship Anarchy Rigid, strictly enforced policies No well-defined life cycle Dictate each step Can’t predict anything of development Inefficient Creativity punished Bureaucracy Lucky to satisfy customer Customer’s needs not adhered to End Result: Unsatisfied Customer

Gathering Requirements Satisfy Functional Requirements Problem Statement Why the System is being Created Terse and Concise Free of Technical Jargon

Gathering Requirements Use Business Objective not Technical Objective Technical Objective “We need a Web-based OLTP architecture for our e-commerce application.” Business Objective "We would like to increase and efficiently service our customer base by 25%."

Functional Requirements Group Process Identify a Champion True customer of the developers Identify Stakeholders Anyone who can delay or derail project All must buy-in

Functional Requirements Utilize facilitated sessions Establish format and rules Solicit specifications from stakeholders Prioritize Functionality Absolutely Required Enhances the product Nice to have but not crucial

Assessing Requirements Identify Domain Experts for each feature Someone highly knowledgeable in the requirements for the function Produce first artifact Document capturing all functional requirements High-level view of the system Use Case Diagram

“Success” of a project Satisfies or exceeds customer’s expectations Developed in a timely fashion Resilient to Change Development Process Controlled, measured, and disciplined Creative, Innovative Iterative, Incremental Control without affecting creativity The Role of Process

The Software Cycle Business Modeling Requirements Analysis & Design Implementation Deployment Test

The Perspective Cycle Conceptual Specification Implementation

Diagrams represent concepts in the domain under study Concepts relate to classes but no direct mapping No regard for the software that might implement it Language-independent Conceptual

Focus on interfaces, not implementation Specification

Mapping to classes is complete Implementation

UML is process-independent RUP is a development lifecycle Produce High Quality Software Meet the user’s needs Predictable schedules and budgets Rational Unified Process

Iterative Maintenance of Models Architecture-Centric Use-Case Driven Object-Oriented Configurable Quality-Control and Risk Management Rational Unified Process

Phases and Iterations