CS 551 Development Process. Organizational Structure SYSTEM BASELINE REQUIREMENTS ALGORITHMS TRAFFIC...

CS 551 Development Process

Organizational Structure

SYSTEM BASELINEREQUIREMENTS

ALGORITHMS

TRAFFICPROJECTIONS

FEATUREENGINEERING

ARCHITECTUREENGINEERING

TRAFFICENGINEERING

ENGINNERINGREPORTS SUPPORT AND OPERATIONS

- COMPUTER CENTER - DEVELOPMENT MACHINE - TEST MACHINE

SOFTWAREDEVELOPMENT

HUMAN FACTORSDEVELOPMENT

SOFTWAREMANUFACTURING INTEGRATION

TO SITES

Development Cycle with Feedback

DEFINE DESIGN DEVELOP MANUFACTURE& DELIVER

TEST

OPERATE,MAINTAIN &EVALUATE

TO SITES

Project Trouble Indicators

No periodic project meetings No Project Manager No active problem list No Software Architect Testing Starts After Development No risk Assessment No independent Test Team

System Performance Resulting from Robust Requirements

Performance

Dynamic Range

Ideal

Discrete Specifications

RobustRequirements

Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Organization Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes9. Responses to the unexpected10. Measurements11. Glossary12. References

MeasurableOperational Value

Release Schedule Targeted Reduction Over PMO

If Release Does Not Reach Target Range Vendor Pays Customer

If Release Exceeds Target Range Customer Pays Vendor

1.0 Target $ 0 ± $5 $ 250K $ 250K

2.0 T+ 6 mo. $10 ± $5 $ 500K $ 500K

3.0 T+ 12 $25 ± $5 $ 1M $ 1M

4.0 T+18 $38 ± $5 $ 2.5M $ 2.5M

5.0 T+24 $50 ± $5 $ 5M $ 5M

GANTT Chart see http://www.mne.psu.edu/me415/resources/docs/gantt%20chart.pdf

CS SENIOR DESIGN CITIGROUP PROJECT

CS SENIOR DESIGN CITIGROUP PHASES

From Project Gantt Chart create this table

Task Who When Current Estimate

Who: The person in charge of the taskWhen: Task committed completion date

owned by the project managerCurrent Estimate: Task estimated completion date owned by the “Who person”

Progress Reports

Progress reports are due 1:00 PM on Wednesdays

Do not send WORD or PDF or text documents, use embedded text only]

Progress Report Contents

Email Subject Line: CS 551, (Project Name) (date)

Address to: [email protected]; [email protected]; (customer)

Email body:

Author:

Team members:

mailto:[email protected]

mailto:[email protected]

Progress Report Sections

1. Customer Interactions and Relations

2. Accomplishments

3. Risks and Contingencies

4. Problems Faced

5. Simplifications

6. Current Estimates


1. Customer Interactions and Relations• Did you meet with your customer?• Do you understand the problem better? • Is your customer happy with your progress?• Do you have a good relationship with your customer?

2. Accomplishments3. Risks and Contingencies4. Problems Faced 5. Simplifications6. Current Estimates


1. Customer Interactions and Relations2. Accomplishments

• What was done since the last progress report, include schedule implications?

• What made the progress possible?

3. Risks and Contingencies4. Problems Faced 5. Simplifications6. Current Estimates



2. Accomplishments

3. Risks and Contingencies• What are the project risks?

• How is each risk managed?

4. Problems Faced

5. Simplifications



1. Customer Interactions and Relations2. Accomplishments3. Risks and Contingencies4. Problems Faced

• Any delays encountered since your last report?• Any new problems?

( “A project with no problems is in deep trouble,” Prof. Bernstein)

5. Simplifications6. Current Estimates


1. Customer Interactions and Relations2. Accomplishments3. Risks and Contingencies4. Problems Faced 5. Simplifications

• How did you simplify your design?• How did you simplify your development process?(Quantitatively support each simplification)




2. Accomplishments

3. Risks and Contingencies

4. Problems Faced

5. Simplifications

6. Current Estimates• Estimate completion dates.

Software Requirements Process

Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype Requirements Management

Develop Use Cases• Focus on Goals

• Identify Actors

• Identify Main Tasks

Use Case Concept• Complete, orthogonal, externally

visible functionality

• Initiated by an actor

• Identifiable value to the actor

OrderingSystem

Customer

<<actor>>AccountSystem

<<actor>>Inventory

Shipping Clerk

ViewStatus

Create & Submit Orders

Role of Software Architect

Assures that the Requirements are valid- use Prototypes in Requirements Stage

Assures that Requirements are quantitative Defines Non Functional Requirements and

Software Trustworthiness. Defines 4+1 views Defines Components and Interface Structures

Kruchten’s “4 + 1”Model for Developing Software Architecture

View + 1 Business Scenarios:

CustomersAll Stakeholders

View 1

Logical:End Users

View 2

Process:System

Integrators

View 3

Physical:Engineers

View 4

Execution:Programmers

Role of Project Manager

Defines and documents Development Process Makes trade-offs among features, schedule,

development cost and quality Chairs Project Meetings Assigns and tracks action items Communicates to Project Members

Waterfall ModelSystem feasibility

Validation

Validation

Software plans &Requirements

Product design

Verification

Verification

Detailed design

Code

Unit test

Integration

Quality assurance

Implementation

Certification

Operations &maintenance Operation

al Reviews

Figure 2: Boehm’s Spiral Model of the Software Process

RqtsAnal.

Proto-Type 1

Concept ofOperation

Risk Analysis

Proto-Type 2

Proto-type 3

OperationalPrototype

Risk Analysis

Risk Analysis

Evaluate Alternatives:

Identify, Resolve Risks

RequirementsValidation

SoftwareRqts

Design Validationand Verification

SoftwareProductDesign

Implemen-tation

AcceptanceTest

Integra-tion & Test

UnitTest

Code

DetailedDesign

Develop & VerifyNext - Level Product

Integrationand Test

Develop-ment Plan

Rqts. PlanLife Cycle

Plan

Commitment

Partition

Plan NextPhases

Determines ObjectivesAlternatives, Constraints

Cumulative Cost

Progress through steps

Role of Software Developers

Designs Software Components Implements Software Documents with code commentary prefaces and

in-line narratives. Unit Tests Checks Interfaces

Development Plan-an evolving document

Name of Project (issue 1 due November 23) Purpose and MOV Team members, their roles, management plan,

QA, ease of use, coding stnds Gantt Chart Current Estimate Table QFD ICED-T

Making a System

ComputerHardware

Binary

Assembler

C Level

FORTRAN, ADA

4GL

JAVA

SOURCE LIBRARIES

DevelopmentComputer

EXECUTABLELIBRARIES

….

DEVELOPERS,PROGRAM ADMINISTRATORS

& SOFTWARE MANUFACTURERS

PRODUCT

…

ProductionComputer

Application

Middleware

UNIX

APPLICATIONDATA BASE

USERS

Source Library

Tools

BUILDING BLOCKS

Role of Testers

Restates Requirements quantitatively and from a test view-see PDF “In Other Words”

Creates test bed for developers Designs and executes:

• Scenario Tests from Use Cases• Integration Tests• Reliability Tests • Stress Tests

Factors Affecting ProductivityCirca 1975

• Competent Management• Quality of people• Level of testing before shipping• Consistency of requirements• Sophistication of programming tools• Modularity of design• Reasonableness of commitments

Development Cycle Circa 1970

Define Requirements

Design Programs, Data Base &

User Documentation

Code andTest Modules

IntegrationTest

SystemTest

InstallSoftware

Verify SystemOperation Live

Operation

TargetSite

Development Cycle for Multiple Sites Circa 1975-80

Define Requirements


User Documentation

Code andTest Modules

IntegrationTest

SystemTest

InstallSoftware


Operation

Site 1

Site Peculiar Tests

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

Define Requirements


User Documentation

Code andTest

Modules

IntegrationTest

SystemTest

InstallSoftware


OperationSite 1

Site Peculiar Tests

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

SoftwareManufactureControls & Builds

SoftwareManufactureBuilds and Ships

Development Cycle with Software Manufacturing Circa 1980-90

Define Requirements

Agile‘Test then Code’

Approach

Quality Assurance

InstallSoftware


OperationSite 1

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

Daily SoftwareBuilds

SoftwareManufactureBuilds and Loads Server

Development Cycle with Software Manufacturing Circa 1990-2000

Agile Software Development

Agile methods Extreme programming Agile application development Software prototyping

Technologies used in agile development

.NET and J2EE Web Design Visual Basic Databases

An iterative development process

Define system deliverables

Integrate increment

Define system deliverables

Specify system increment

Build systemincrement

Validate increment

Validate systemDone?

No

Deliver systemYes

Advantages of incremental development

Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.

User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

Agile methods

Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods: Focus on the code rather than the design; Are based on an iterative approach to software development; Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements.

Agile methods are probably best suited to small/medium-sized business systems or PC products.

Principles of agile methods

Principle Description

Customer involvement The customer should be closely involved throughout the development process. Their role is provide and prioritise new system requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

Problems with agile methods

It can be difficult to keep the interest of customers who are involved in the process.

Team members may be unsuited to the intense involvement that characterises agile methods.

Prioritising changes can be difficult where there are multiple stakeholders.

Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to

iterative development.

Extreme programming

Perhaps the best-known and most widely used agile method.

Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only

accepted if tests run successfully.

The XP release cycle

Break downstories to tasks

Select userstories for this

releasePlan release

Releasesoftware

Evaluatesystem

Develop/integratetest software

Extreme programming practices

Incremental planning Requirements are recorded on Story Cards and the Stories to beincluded in a release are determined by the time available andtheir relative priority. The developers break these Stories intodevelopment ŌTasksÕ.

Small Releases The minimal useful set of functionality that provides businessvalue is developed first. Releases of the system are frequent andincrementally add functionality to the first release.

Simple Design Enough design is carried out to meet the current requirementsand no more.

Test first development An automated unit test framework is used to write tests for a newpiece of functionality before that functionality itself isimplemented.

Refactoring All developers are expected to refactor the code continuously assoon as possible code improvements are found. This keeps thecode simple and maintainable.

Extreme programming practicesPair Programming Developers work in pairs, checking each otherÕs work and

providing the support to always do a good job.

Collective Ownership The pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own all thecode. Anyone can change anything.

Continuous Integration As soon as work on a task is complete it is integrated into thewhole system. After any such integration, all the unit tests in thesystem must pass.

Sustainable pace Large amounts of over-time are not considered acceptable as thenet effect is often to reduce code quality and medium termproductivity

On-site Customer A representative of the end-user of the system (the Customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

XP and agile principles

Incremental development is supported through small, frequent system releases.

Customer involvement means full-time customer engagement with the team.

People not process through pair programming, collective ownership and a process that avoids long working hours.

Change supported through regular system releases. Maintaining simplicity through constant refactoring of

code.

Testing in XP

Test-first development. Incremental test development from scenarios. User involvement in test development and

validation. Automated test harnesses are used to run all

component tests each time that a new release is built.

Pair programming

In XP, programmers work in pairs, sitting together to develop code.

This helps develop common ownership of code and spreads knowledge across the team.

It serves as an informal review process as each line of code is looked at by more than 1 person.

It encourages refactoring as the whole team can benefit from this.

Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

COTS reuse

An effective approach to rapid development is to configure and link existing off the shelf systems.

For example, a requirements management system could be built by using: A database to store requirements; A word processor to capture requirements and format reports; A spreadsheet for traceability management;

Back to back testing

Test data

Resultscomparator

Systemprototype

Applicationsystem

Differencereport

Software Factory

DESIGNERS

- CODE- DOCUMENT- FIX BUGS

CONTROL PROGRAMS& PROCEDURES

SourceControl

ChangeManagement

TrackingSystem

SupportPrograms

SourceLib.

ChangeRequests

Doc.Library

ReleaseArchives

Build System

ShippingUtilities

BaseLibraries

Application

Files

Released ProductTo TestTeam

Reports

ModificationRequests

Released

Product

To SitesMiddleware, Tools and Operating System

Source Code Management

• Store, update and retrieve all versions • Manage code ownership• Control updating privileges• Identify accurate version of retrieved source• Track changes• Maintain build database, tools and machine

Release Flow

•CODE•PROCEDURES•DOCUMENTATION

DEVELOPMENTSHOPS

SOFTWAREMANUFACTURING

SOFTWAREMANUFACTURING

COOPERATIVETESTING

RELEASEPACKAGES

MODIFICATIONREQUEST(MR)

COMPONENTTEST

SYSTEM INTEG.TEST

SITES

N - 1

N

DEVELOPMENT ENVIRONMENT EXECUTION ENVIRONMENT

MODULE D

MODULE C

MODULE B

MODULE A

Purpose of Release Documents

• Describe features• Describe corrections to troubles• Cross reference software dependencies• Specify limitations or deficiencies• Provide special installation instructions and provide data conversion instructions• Specify training• Identify new, changed or deleted documents• Provide software source code• Maintain product lists

Software Change

Cultural Technical

Business

Innovation

&

Investment

CS 551 Development Process. Organizational Structure SYSTEM BASELINE REQUIREMENTS ALGORITHMS TRAFFIC...

Documents

Transcript of CS 551 Development Process. Organizational Structure SYSTEM BASELINE REQUIREMENTS ALGORITHMS TRAFFIC...