best practices of software engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Best Practices of Software Engineering PowerPoint Presentation
Download Presentation
Best Practices of Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 74

Best Practices of Software Engineering - PowerPoint PPT Presentation


  • 250 Views
  • Uploaded on

Best Practices of Software Engineering. Objectives. What we will learn: Best Practices of Software Engineering. Best Practices Reinforce Each Other. Best Practices. Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Best Practices of Software Engineering' - alan-sampson


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
objectives
Objectives

What we will learn:

  • Best Practices of Software Engineering
best practices reinforce each other
Best Practices Reinforce Each Other

Best Practices

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Ensures users are involved

as requirements evolve

Validates architectural

decisions early on

Addresses complexity of

design/implementation incrementally

Measures quality early and often

Evolves baselines incrementally

develop iteratively

Each iteration results in an executable release

Develop Iteratively
  • Iterative development produces an executable

3. Requirements

4. Analysis & Design

2. Planning

1. Initial

Planning

5. Implementation

Management

Environment

(on-going)

6. Test

8. Evaluation

7. Deployment

managing requirements
Managing Requirements

Ensures that you

  • solve the right problem
  • build the right system

by taking a systematic approach to

  • eliciting
  • organizing
  • documenting
  • managing

the changing requirements of a software application.

use component architectures
Use Component Architectures

Software architecture needs to be:

purpose of a component based architecture

Application-

specific

Business-

specific

Middleware

System-

software

Purpose of a Component-Based Architecture
  • Basis for reuse
    • Component reuse
    • Architecture reuse
  • Basis for project management
    • Planning
    • Staffing
    • Delivery
  • Intellectual control
    • Manage complexity
    • Maintain integrity

Component-based architecture with layers

model visually uml
Model Visually (UML)
  • Captures structure and behavior
  • Shows how system elements fit together
  • Keeps design and implementation consistent
  • Hides or exposes details as appropriate
  • Promotes unambiguous communication
    • The UML provides one language for all practitioners.
visual modeling with the unified modeling language

Static Diagrams

Class

Diagrams

Use-Case

Diagrams

Object

Diagrams

Sequence

Diagrams

Component

Diagrams

Communication

Diagrams

Models

Deployment

Diagrams

State Machine

Diagrams

Activity

Diagrams

Visual Modeling with the Unified Modeling Language
  • Multiple views
  • Precise syntax and semantics

Dynamic Diagrams

continuously verify quality
Continuously Verify Quality

Software problems are100 to 1000 times more costlyto find and repair after deployment

  • Cost to Repair Software
  • Cost of Lost Opportunities
  • Cost of Lost Customers

Cost

Inception

Elaboration

Construction

Transition

testing dimensions of quality
Testing Dimensions of Quality

Usability

  • Test application from the perspective of convenience to the end user.

Functionality

Reliability

  • Test that the application behaves consistently and predictably.
  • Test the accurate workings of each usage scenario.

Supportability

Performance

  • Test the ability to maintain and support the application under production use.
  • Test the online response under average and peak loading.
manage change

Configuration Management is more than just check-in and check-out

Manage Change
  • To avoid confusion, have:
    • Secure workspaces for each developer
    • Automated integration/build management
    • Parallel development

Workspace

Management

Process

Integration

Parallel

Development

Build

Management

manage change continued
Manage Change (continued)
  • Unified Change Management (UCM) involves:
    • Management across the lifecycle
      • System
      • Project management
    • Activity-based management
      • Tasks
      • Defects
      • Enhancements
    • Progress tracking
      • Charts
      • Reports
rational unified process implements best practices
Rational Unified Process Implements Best Practices

Best Practices

Process Made Practical

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

achieving best practices
Iterative approach

Guidance for activities and artifacts

Process focus on architecture

Use cases that drive design and implementation

Models that abstract the system

Achieving Best Practices
a team based definition of process
A Team-Based Definition of Process

A process defines Who is doing What, When, and How, in orderto reach a certain goal.

New or changed

requirements

New or changed

system

Software Engineering

Process

process structure lifecycle phases

Inception

Elaboration

Construction

Transition

Process Structure - Lifecycle Phases

The Rational Unified Process has four phases:

  • Inception – Define the scope of the project
  • Elaboration – Plan the project; specify features and baseline architecture
  • Construction – Build the product
  • Transition – Transition the product into the end-user community

Time

objectives1
Objectives

What we will learn:

  • Define an iterative and adaptive process.
  • Define fundamental concepts in the Unified Process.
unified process
Unified Process
  • Iterative development is a skillful approach to software development, and lies at the heart of how OOA/D is presented
  • The Unified Process is an example iterative process for projects using OOA/D
    • In particular, the Rational Unified Process or RUP is a detailed refinement of the Unified Process
  • The UP is very flexible and open, and encourages including skillful practices from other iterative methods,
    • such as from Extreme Programming (XP), Scrum, and so forth
from sequential to iterative lifecycle
From sequential to iterative lifecycle

R: requirements; D: design; C: coding, unit test; T: integration, test

R

D

C

T

R

R

R

D

D

D

C

C

C

T

T

T

Time

iterative development
Iterative Development
  • ID is the best practice using the UP to develop software
  • Development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.
iterations
Iterations
  • Each iteration must result in production quality code. This implies that each iteration includes exhaustive testing!
  • The code may be incomplete (e.g., with stubs for functions identified but not yet implemented).
  • Note the contrast with rapid prototyping methodologies.
  • Early iterations should address high-risk parts of the system.
example
Example

in a three-week iteration early in the project, perhaps one hour Monday morning is spent in a kickoff meeting with the team clarifying the tasks and goals of the iteration. Meanwhile, one person reverse-engineers the last iteration's code into UML diagrams (via a CASE tool), and prints and displays noteworthy diagrams. The team spends the remainder of Monday at whiteboards, working in pairs while agile modeling, sketching rough UML diagrams captured on digital cameras, and writing some pseudocode and design notes. The remaining days are spent on implementation, testing (unit, acceptance, usability, …), further design, integration, and daily builds of the partial system. Other activities include demonstrations and evaluations with stakeholders, and planning for the next iteration.

We should avoid:

  • A rush to code
  • A long drawn-out design step that attempts to perfect all details of the design before programming.
benefits of iterative development
Benefits of iterative development
  • less project failure, better productivity, and lower defect rates
  • early rather than late mitigation of high risks
  • early visible progress
  • early feedback
    • user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders
  • managed complexity
  • the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration
agile methods
Agile Methods
  • Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agility rapid and flexible response to change.
the agile principles not in details
The Agile Principles ( Not in Details)
  • 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • 2. Welcome changing requirements, even late in development.
    • Agile processes harness change for the customer's competitive advantage.
  • 3. Deliver working software frequently, from a couple of weeks to a couple of months
  • 4. Business people and developers must work together daily throughout the project.
  • 5. Build projects around motivated individuals.
    • Give them the environment and support they need, and trust them to get the job done.
  • 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
the agile principles
The Agile Principles
  • 7. Working software is the primary measure of progress.
  • 8. Agile processes promote sustainable development.
  • 9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • 10. Continuous attention to technical excellence and good design enhances agility.
  • 11. Simplicity the art of maximizing the amount of work not done is essential.
  • 12. The best architectures, requirements, and designs emerge from self-organizing teams.
  • 13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
up best practices and concepts
UP Best Practices and Concepts
  • tackle high-risk and high-value issues in early iterations
  • continuously engage users for evaluation, feedback, and requirements
  • build a cohesive, core architecture in early iterations
  • continuously verify quality; test early, often, and realistically
  • apply use cases
  • model software visually (with the UML)
  • carefully manage requirements
  • practice change request and configuration management
the up phases
The UP Phases

A UP project organizes the work and iterations across four major phases:

  • 1. Inception
    • approximate vision, business case, scope, vague estimates.
  • 2. Elaboration
    • refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
  • 3. Construction
    • iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
  • 4. Transition
    • beta tests, deployment.
inception
Inception

Inception

Elaboration

Construction

Transition

Purpose:

  • Establish some initial common vision for the objectives of the project,
  • Determine if it is feasible, and
  • Decide if it is worth some serious investigation in elaboration.
  • The good idea—specifying the end-product vision and its business case and defining the scope of the project
  • Concluded by the lifecycle objective (LCO) milestone
inception phase
Inception phase
  • Lasts for one iteration
  • Is basically a feasibility study
  • Doesn't involve requirements analysis
  • Identify most important Use Cases
  • Write Vision
  • Write Business Case & Development Case
objectives of the inception phase
Objectives of the Inception Phase
  • Establish the project’s software scope and boundary conditions
  • Discriminate critical use cases of the system
  • Exhibit at least one candidate architecture
  • Estimate overall cost and schedule for entire project
  • Estimate risks
activities of the inception phase
Activities of the Inception Phase
  • Formulate scope of project
  • Plan and prepare business case
  • Evaluate alternatives for risk management, staffing, project plan, and trade-offs between cost, schedule, and profitability
  • Synthesize candidate architecture
  • Evaluate trade-offs in design and assess make/buy/reuse decisions so that cost, schedule, and resources can be estimated
outcome of the inception phase
Outcome of the Inception Phase
  • Vision document
  • Use-case model survey
  • Initial project glossary
  • Initial business case
    • Business context
    • Success criteria
    • Financial forecast
  • Initial risk assessment
  • Project plan, which shows phases / iterations
milestone lifecycle objective
Milestone: Lifecycle Objective

Inception

Elaboration

Construction

Transition

Lifecycle

Objective

  • Evaluation criteria for inception phase:
    • Stakeholder concurrence on scope definition and cost and schedule estimates
    • Requirements understanding – evidenced by fidelity of primary use cases
    • Credibility of cost and schedule estimates, priorities, risks, and development process
    • Depth / breadth of any architectural prototype
    • Actual expenditures versus planned expenditures
rational unified process inception
Rational Unified Process – Inception

Time

Phases

Workflows

Inception

Elaboration

Construction

Transition

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Content

Deployment

Configuration &

Change Management

Project Management

Environment

Initial

E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Iterations

elaboration phase
Elaboration Phase
  • Purpose: analyze problem domain, establish a sound architectural foundation, develop project plan, and eliminate project’s highest-risk elements
  • An executable architecture prototype built in one or more iterations
    • address critical use cases identified in inception phase – expose project’s major technical risks.

Inception

Elaboration

Construction

Transition

elaboration phase1
Elaboration phase
  • Multiple iterations
  • Mainly analysis
    • Flesh out Use Cases
    • Add more Use Cases
    • Supplemental specification
    • Glossary
    • Lots of customer involvement
  • Some design
  • Some implementation
    • Wide, rather than high, implementation
objectives of the elaboration phase
Objectives of the Elaboration Phase
  • Define, validate, and baseline the architecture as rapidly as practical
  • Baseline the vision
  • Baseline a high fidelity plan for the construction phase
  • Demonstrate that the baseline architecture will support this vision for a reasonable cost in a reasonable time
activities of the elaboration phase
Activities of the Elaboration Phase
  • Vision is elaborated
  • A solid understanding is established of the most critical use cases
  • The process, infrastructure, and development environment are elaborated
  • The architecture is elaborated and the components are selected
outcomes of the elaboration phase
Outcomes of the Elaboration Phase
  • A use-case model in which all use cases have been identified in the use-case model survey, all actors have been identified, and most use-case descriptions have been developed
  • Supplementary requirements that capture the nonfunctional requirements and any requirements that are not associated with the specific use case
outcomes of the elaboration phase continue
Outcomes of the Elaboration Phase (continue)
  • A software architecture description
  • An executable architectural prototype
  • A revised risk list and a revised business case
  • A development plan for the overall project
  • An updated development case that specifies the process to be used
  • A preliminary user manual (optional)
milestone lifecycle architecture
Milestone: Lifecycle Architecture
  • Examine
    • detailed system objectives and scope
    • choice of architecture
    • resolution of major risks

Inception

Elaboration

Construction

Transition

Lifecycle

Architecture

evaluation criteria
Evaluation Criteria
  • Is the vision of the product stable?
  • Is the architecture stable?
  • Does the executable demonstration show that the major risk elements have been addressed and credibly resolved?
  • Is the construction phase plan sufficiently detailed and accurate? Is it backed up with a credible basis for the estimates?
  • Do all stakeholders agree:
    • current vision can be achieved if the current plan is executed to develop the complete system, in the context of the current architecture?
  • Is the actual resource expenditure versus planned expenditure acceptable?
rational unified process elaboration
Rational Unified Process – Elaboration

Time

Phases

Workflows

Inception

Elaboration

Construction

Transition

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Content

Deployment

Configuration &

Change Management

Project Management

Environment

Initial

E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Iterations

the construction phase
The Construction Phase
  • Purpose: all remaining components and application features are developed and integrated into the product, and all features are tested thoroughly

Inception

Elaboration

Construction

Transition

construction phase
Construction phase
  • Multiple iterations
  • Some analysis
  • Mainly design and implementation
    • Add additional paths to Use Cases
objectives of the construction phase
Objectives of the Construction Phase
  • Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework
  • Achieve adequate quality as rapidly as practical
  • Achieve useful versions (a, b, and other test releases) as rapidly as practical
activities of the construction phase
Activities of the Construction Phase
  • Resource management, resource control, and process optimization
  • Complete component development and testing against the defined evaluation criteria
  • Assessment of product releases against acceptance criteria for the vision
outcome of the construction phase
Outcome of the Construction Phase
  • Product ready to put in the hands of its end users
  • Product consists of
    • Software product itself – integrated on the adequate platforms
    • User manuals
    • Description of the current release
milestone initial operational capability
Milestone: Initial Operational Capability
  • Decide whether software, sites, and users are ready to become operational without exposing project to high risks
  • Called a brelease
    • N.B. brelease often confused with a test

Inception

Elaboration

Construction

Transition

Initial

Operational

Capability

evaluation criteria for the construction phase
Evaluation Criteria for the Construction Phase
  • Is this product release stable and mature enough to be deployed in the user community?
  • Are all stakeholders ready for the transition into the user community?
  • Are the actual resource expenditures versus planned expenditures still acceptable?
rational unified process construction
Rational Unified Process – Construction

Time

Phases

Workflows

Inception

Elaboration

Construction

Transition

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Content

Deployment

Configuration &

Change Management

Project Management

Environment

Initial

E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Iterations

transition phase
Transition Phase
  • Purpose: move software product into user community
  • Occurs when baseline mature enough to be deployed in the end-user domain
    • some useable subset has been completed to an acceptable level of quality
    • user documentation is available so transition to user will provide positive results for all parties

Inception

Elaboration

Construction

Transition

transition phase1
Transition phase
  • Several iterations
  • Beta testing
  • Deployment
  • Development of support artifacts
  • Beta testing to validate the new system against user expectations
  • Parallel operation with the legacy system that the project is replacing
  • Conversion of operational databases
  • Training of users and maintainers
  • Rollout of the product to the marketing, distribution, and sales teams
objectives of the transition phase
Objectives of the Transition Phase
  • Achieve user self-supportability
  • Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision
  • Achieve the final product baseline as rapidly and cost-effectively as practical
activities of the transition phase
Activities of the Transition Phase
  • Deployment-specific engineering – cutover, commercial packaging and production, sales rollout, and field personnel training
  • Tuning activities, including bug fixing and enhancement for performance and usability
  • Assessing the deployment baselines against the vision and the acceptance criteria for the product
milestone product release
Milestone: Product Release
  • Decide whether
    • objectives were met
    • another development cycle should start
  • This milestone may coincide with the end of the inception phase for the next cycle

Inception

Elaboration

Construction

Transition

Product

Release

evaluation criteria1
Evaluation Criteria
  • Evaluation criteria for transition phase includes:
    • Is the user satisfied?
    • Are actual resources expenditures versus planned expenditures still acceptable?
rational unified process transition
Rational Unified Process – Transition

Time

Phases

Workflows

Inception

Elaboration

Construction

Transition

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Content

Deployment

Configuration &

Change Management

Project Management

Environment

Initial

E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Iterations

iterations releases and milestones
Iterations, Releases, and Milestones

Inception

Elaboration

Construction

Transition

Time

Iteration

#1

Iteration

#2

Iteration

#3

Iteration

#4

Iteration

#5

Iteration

#6

Iteration

#7

Iteration

#8

First External

Release

(e.g., “b”)

Minor

Milestone

Final

Release

Internal

Release

the up disciplines
The UP Disciplines
  • A discipline is a set of activities (and related artifacts – Work Products) in one subject area
  • Business Modeling
    • When developing a single application, this includes domain object modeling. When engaged in large-scale business analysis or business process reengineering, this includes dynamic modeling of the business processes across the entire enterprise.
  • Requirements
    • Requirements analysis for an application, such as writing use cases and identifying non-functional requirements.
  • Design
    • All aspects of design, including the overall architecture, objects, databases, networking, and the like.
the up disciplines1
The UP Disciplines
  • UP involves a lot of disciplines (not just programming):
    • Business Modeling
    • Requirements
    • Design
    • Implementation
    • Project Management
    • Testing
    • Environment
    • Deployment
    • Configuration
    • Change Management
    • …and more…
rational unified process two dimensions
Rational Unified Process – Two Dimensions

Time

Phases

Workflows

Inception

Elaboration

Construction

Transition

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Content

Deployment

Configuration &

Change Management

Project Management

Environment

Initial

E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Iterations

up artifacts
UP artifacts
  • UP includes dozens of artifact types, including:
    • Vision
    • Business Case
    • Development Case -- Choice of artifacts for a project, discipline & schedule for each.
    • Phase Plan -- What activities and artifacts will be done in each phase?
    • Iteration Plan -- Exactly what use cases, etc will be done in each iteration?
    • Use Case
    • Domain Model
    • State Diagram
up artifacts continued
UP artifacts (continued)
  • More UP artifacts:
    • Design Model
    • Data Model
    • Supplementary Specification
    • Glossary
    • Risk List
    • Risk Management Plan
    • Prototype
    • Software Architecture Document
    • Implementation Model
    • Test Model
up artifacts continued1
UP artifacts (continued)
  • Almost all artifacts are optional.
  • Formats of artifacts are fairly loose.
  • Create only those which add value to your final product.
  • In your semester project, you won't get to choose -- certain artifacts are required.
you know you didn t understand up when
You Know You Didn't Understand UP When…
  • You try to define most of the requirements before starting design or implementation.
    • try to define most of the design before starting implementation;
    • try to fully define and commit to an architecture before iterative programming and testing.
  • You spend days or weeks in UML modeling before programming, or you think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail.
    • you regard programming as a simple mechanical translation of these into code.
  • You think that inception = requirements, elaboration = design, and construction = implementation.
  • You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
  • You believe that a suitable iteration length is three months long, rather than three weeks long.
  • You think that adopting the UP means to do many of the possible activities and create many documents, and you think of or experience the UP as a formal, fussy process with many steps to be followed.
  • You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.