Software development processes - PowerPoint PPT Presentation

Software development processes l.jpg
Download
1 / 56

Do we have the expertise/personnel to successfully create the system? ... No all nighters, no superheros. Overwork ultimately decreases productivity. Concerns About ...

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

Download Presentation

software development processes

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


Software development processes l.jpg

Software Development Processes

CSCI 5801: Software Engineering


Software development processes2 l.jpg

Software Development Processes


Major stages l.jpg

Major Stages

Major steps followed by all processes:

  • Feasibility study

  • Requirements Analysis

  • Architectural Design

  • Implementation and Testing

  • Product Delivery

  • Maintenance

What we will focus on for now


Feasibility studies l.jpg

Feasibility Studies

“Should we build this system?”

  • Will it solve the customer’s problems?

  • Is it too costly?

    • Development costs

    • Hardware needed

    • User training

    • Maintenance

  • Do we have the expertise/personnel to successfully create the system?


Requirement analysis l.jpg

Requirement Analysis

“What should the system do?”

  • Identification of stakeholders and needs

  • Elicitation of requirements

  • Documentation of requirements in manner understood by developers and customers

  • Validation of requirements

  • Prototyping


Software design l.jpg

Software Design

“How should system work?”

  • Determination of overall system architecture

  • Decomposition into simpler modules/subsystems/objects

  • Formal design of interfaces between subsystems


Implementation and testing l.jpg

Implementation and Testing

  • Implementation:

    • Individuals/small teams implement code at object level

    • New objects integrated into overall system

  • Testing:

    • Unit testing of individual objects

    • Integration testing to insure system functions correctly when new objects added


Project delivery l.jpg

Project Delivery

  • Acceptance Testing

    • Demonstrations of system to customer that product meets requirements

    • Beta testing by users

  • Installation

  • User training


Maintenance l.jpg

Maintenance

  • Different types of maintenance

    • Bug fixes

    • Adapting to new environments

    • Responding to evolution in requirements

  • 50% to 70% of resources spent on maintenance over lifetime of software!


The big questions l.jpg

The Big Questions

  • How many times is each phase done?

    • Waterfall models: once

    • Incremental/agile models: several cycles

    • Is a product released each time?

  • What is each phase expected to produce?

    • How do we know we are done?


The big questions11 l.jpg

The Big Questions

  • How much time to schedule for each phase?

    • Reasonable estimates of delivery time

    • Allocation resources between different projects

  • What do you do if you are not finished?

    • Release less product?

    • Request extension?


How long do phases take relatively l.jpg

How long do phases take? (relatively)

design 15%

coding 20%

requirements

engineering 10%

specification 10%

testing 45%


Scheduling l.jpg

Scheduling

  • “40-20-40” rule:

    • 40% of time on requirements/design

    • 20% on coding

    • 40% on testing

  • Must allocate sufficient time for requirements, design, and testing“The longer you wait to begin coding, the sooner you will finish.”-Hans Van Vliet


The waterfall model l.jpg

The Waterfall Model

Feasibility study

Steps done sequentially

Requirements

Architectural design

Object design

Unit coding and testing

Integration coding and testing

Each phase completed before next begun

Acceptance & Delivery

Maintenance


Waterfall model document heavy l.jpg

Waterfall Model Document Heavy

  • Requirements stage Requirements Specification Document

    • Formal list of functional and non-functional requirements for delivered system

    • Sufficiently detailed to be understood by client, developers

    • Treated like legal document agreed on by all


Waterfall model document heavy16 l.jpg

Waterfall Model Document Heavy

  • Design stage  Design Document

    • Overall system architecture

    • APIs for major modules

    • Sufficiently detailed for all developers to unambiguously understand their role

  • Implementation stage  Testing Plan

    • Lists of tests to be performed at each milestone

    • Results of tests


Problems with the waterfall model l.jpg

Problems with the Waterfall Model

  • Cannot separate phases easily

    • Will always need to revisit previous steps

  • Need to gather some requirements before determining feasibility

  • Will find further questions about requirements during design

  • Will modify design during implementation

  • Will revisit all stages during maintenance


Always revisiting earlier phases l.jpg

Always revisiting earlier phases

Phase

Implementation

(& unit testing)

Integration

testing

Acceptance

testing

Design

Activity

Integration

testing

4.7

43.4

26.1

25.8

Implementation

(& unit testing)

6.9

15.9

70.3

6.9

49.2

34.1

10.3

6.4

Design


Expect to revisit earlier phases l.jpg

Expect to revisit earlier phases

  • At each phase plan to revisit earlier phases

    • Allocate time and meetings for this process

  • When collecting requirements, ask if project still feasible

  • When creating design, look for unresolved requirements issues

  • When writing code, reevaluate design

  • Plan to reevaluate entire system during maintenance


Modified waterfall model l.jpg

Modified Waterfall Model

Feasibility study

Requirements

Architectural design

Object design

Unit coding and testing

Integration coding and testing

Acceptance & Delivery

Maintenance


Modified waterfall still insufficient l.jpg

Modified Waterfall Still Insufficient

  • Cannot validate earliest phases until latest steps

Can’t evaluate requirements until customer acceptance testing

Requirements

Acceptance testing

Can’t evaluate architecture until entire system put together during integration

Architectural design

Integration testing

Object design

Unit testing


Biggest problem requirements l.jpg

Biggest Problem: Requirements

  • Customers very bad at specifying all requirements verbally

    • Customers, developers speak different languages

    • Requirements are hard to understand until users can play with operational system

    • In waterfall model, no operational system available until delivery

  • Mistakes in requirements are the most expensive to correct


Iterative development l.jpg

Iterative Development


Iterative refinement l.jpg

Iterative Refinement

  • Create multiple versions of product

    • Perform entire development cycle several times

    • Fast development cycle (weeks instead of months)

  • Often includes risk analysis at each cycle

    • Identification of possible failure points

    • Consideration of alternatives


Prototypes l.jpg

Prototypes

  • First versions are prototypes

    • Not released, or used in final version

    • Can be code, mockup UI, etc.

  • Evaluate prototype at end of each cycle

    • Review it with clients

    • Test it with users

    • Use results to improve the understanding of the requirements


Sometimes called spiral model l.jpg

Sometimes called Spiral Model


Iterative development lowers risk l.jpg

Iterative Development Lowers Risk

  • Better understanding of customer needs

  • Major errors in requirements, design caught early (before release)

  • Potential disadvantage:

    • Must throw away prototypes at end of each stage or final release will contain unreliable code

    • May require more development time


Incremental development l.jpg

Incremental Development

  • Like iterative, but release product each cycle

    • Can sell some product faster

Identification and Prioritization

Release #1

Release #2


Incremental development29 l.jpg

Incremental Development

  • Initial stage: Determine and prioritize main features

    • What features must be in every version for initial versions to sell?

    • What additional features can be built on those features, and result in further sales?

    • What upgrades would keep customers happy?

  • Can reprioritize each cycle and add new feature based on user feedback


Iterative vs incremental development l.jpg

Iterative vs. Incremental Development

  • Iterative

    • Get the entire system working somewhat well

    • Then improve features throughout the system

  • Incremental

    • Get some features of the system working perfectly

    • Then add more features to the system


Iterative vs incremental questions l.jpg

Iterative vs. Incremental Questions

  • Incremental development only works if

    • Can subdivide system into discrete features

    • Don’t need to have entire system working for some users to be interested

    • Can easily release new features to existing customers

      • True for online release

      • Not true for shrinkwrapped/embedded software


Agile models l.jpg

Agile Models


Agile manifesto l.jpg

Agile Manifesto

  • Individuals and interactionsover processes and tools

  • Working software over comprehensive documentation

  • Customer collaborationover contract negotiation

  • Responding to change over following a plan

    Note: More of a philosophy than an actual process


Why agile software development l.jpg

Why Agile Software Development?

  • Waterfall model can be more management centered than developer centered

    • Lots of time-consuming paperwork and reports

    • Sticking to plans even if no longer viable

    • Adversarial relationships with clients to preserve legal cover


Why agile software development35 l.jpg

Why Agile Software Development?

  • Requirements can change quickly

    • Much faster than waterfall-based systems can cope withThis can often take 6 to 12 months

  • Major goal: shorten development time

    • Weeks instead of months

    • Released in increments

Requirements

Coding and testing

Design


Agile software development l.jpg

Agile Software Development

  • Simplified requirements stage:

    • No attempt to determine requirements for entire system, just quickly develop requirements for next increment

    • Prioritize features to make completion possible in limited time

    • Immediate feedback available from customer, ideally on site


Agile software development37 l.jpg

Agile Software Development

  • Immediate implementation instead of design

    • Knowledgeable, skilled, empowered developers with ability to write good code

    • Automated testing tools used to speed up testing and continuously insure correctness

    • Rework design after release to correct bad coding and make next increment easier (refactoring)


Agile software development38 l.jpg

Agile Software Development

Customer provides short and simple requirements for next increment

Refactoring to improve design

Prioritizerequirements

System and

acceptance tests

Write and rununit tests

Implement

Delivery


Rapid application development l.jpg

Rapid Application Development

  • Experienced SWAT (skilled workers with advanced tools) teams

    • Automated testing, version control tools used to speed up development

    • Developers empowered to make decisions on fly

  • Time boxes: fixed time periods for increment

    • Usually 2 – 4 weeks

    • Accomplish as much as possible within that time

    • Deliver whatever is accomplished on time


Rapid application development40 l.jpg

Rapid Application Development

  • Prioritization of features to insure most critical ones completed within time box (triage)

  • MoSCoW designation of priorities:

    • Must haves: top priority requirements

    • Should haves: highly desirable

    • Could haves: if time allows

    • Won’t haves: will not be don’t this increment


Dynamic systems delivery model l.jpg

Dynamic Systems Delivery Model

  • Overall development process based on RAD

  • Additional phases:

    • Feasibility study (can we do this?)

      • Feasibility report, development plan, quick prototype

    • Business study (is there a market for this?)

    • Post-project phase (how can we improve this?)

      • Identify what worked well and what did not

  • Ambassador Users and/or Facilitated Workshops

    • Customers on call and/or focus groups available


Dynamic systems delivery model42 l.jpg

Dynamic Systems Delivery Model

Feasibility

Study

Business

Study

Time box-based incremental development

Post-project evaluation

Customers/users

Prototype


Extreme programming l.jpg

Extreme Programming


13 practices of extreme programming l.jpg

13 Practices of Extreme Programming

  • Whole team: client part of the team

  • Metaphor: common analogy for the system

  • The planning game, based on user stories

  • Simple design

  • Small releases (e.g. 2 weeks)

  • Customer tests

  • Pair programming

  • Test-driven development: tests developed first

  • Design improvement (refactoring)

  • Collective code ownership

  • Continuous integration: system always runs

  • Sustainable pace: no overtime

  • Coding standards


Xp practices customer role l.jpg

XP Practices: Customer Role

  • Customer is part of the development team

    • Cooperative, not adversarial relationship

    • Should always be available to answer questions about requirements and to test system

      • Ideally, on site in same room

    • Should help develop test cases

    • Should be empowered to make decisions


Xp practices requirement engineering l.jpg

XP Practices: Requirement Engineering

  • Each increment is small release

    • Generally implements single requirement

  • Expressed as simple “user story”

    • Role of users, system in simple scenario

      “Fred wants to register for the MW 10:00 section of CSIS 2610. He logs onto BANNER and tries to add it, but is told that it is closed. BANNER provides a list of open sections, which include one at MW 2:00. Fred is ok with that time, so he registers for that section.”


Xp practices design l.jpg

XP Practices: Design

  • Keep design as simple as possible

    • Simple models, simple architecture, simple code

    • Minimizes possibility of error, makes change easier

  • Design based on simple metaphors

    • “Class roster”, “list of courses being taken”,…

  • Iterative design improvement

    • Refactor design after increment to make next increment easier


Xp practices coding and testing l.jpg

XP Practices: Coding and Testing

  • Test-driven development

    • Write tests first, then write code

    • Test cases suggested by customer

  • Continuous integration

    • Regularly check to see if the system is on track

    • Use automated testing tools to insure that any change does not break system


Xp practices teamwork l.jpg

XP Practices: Teamwork

  • Pair programming

    • All code is written with a “co-pilot” who can help correct code and suggest improvements

    • Share single terminal

    • Regularly swap roles

  • Collective code ownership

    • Everyone can modify any code in project

  • Coding standards

    • Standardized variable naming, spacing, etc. for universal readability


Xp practices realism l.jpg

XP Practices: Realism

  • The planning game:

    • Meet overall client needs one increment at a time

    • Design around 2-week increments

  • Work at a sustainable pace:

    • No all nighters, no superheros

    • Overwork ultimately decreases productivity


Concerns about agile xp development l.jpg

Concerns About Agile/XP Development

  • Available & empowered customer may not be realistic

    • Decision makers’ time too valuable to stay on site

  • No overall plan for architecture to meet all needs

    • Current design only based on current increment

    • Refactoring for next increment may become time consuming

  • Knowledge lives in developers heads, not on paper

    • What if someone leaves?

    • Mollified by pair programming, collective code ownership

  • Collective coding = little individual responsibility

    • Who insures a specific requirement is met?


So which process to choose l.jpg

So…Which process to choose?

  • Waterfall good choice for small systems whose requirements can be fully understood before any design or coding

  • Spiral good choice for larger systems with vague requirements and many alternatives for designing and coding

  • Agile good choice for systems something verysmall but useful can be created and then expanded upon in small increments


Often combine different models l.jpg

Often combine different models

  • Example: Client-server web site to sell used textbooks

Web server

Web pages

Textbook database


Often combine different models54 l.jpg

Often combine different models

  • Risk analysis:

    • What is known? What requires more information?

Web server

Web pages

Textbook database

High risk: not sure what interfaces should look like, site will fail if customers do not find usable

Low risk: very similar to other e-commerce sites, can use similar code or buy off shelf


Often combine different models55 l.jpg

Often combine different models

  • Use iterative/agile model to develop web page UI

  • Once stabilized, use simple waterfall for rest

Define basic requirements for site, initial site design

Implement prototype of pages

Implement database and server software

Release

Redesign pages and site structure

User testing of prototype, user stories for missing features


Often combine different models56 l.jpg

Often combine different models

Initial version of web site created

Released to customers

Design and implement changes

Determine most needed bug fixes and additional features

Get user feedback about site

Use modified waterfall to develop initial version

Use agile development to release upgrades quickly


  • Login