Software Engineering Review - Software Process

IF3250 Proyek Perangkat Lunak Rekayasa Perangkat Lunak-Review

Sem I 2013/2014

Pendahuluan Software Application Domain Software Engineering Definitions System/Product Engineering Hierarchy From Requirements to User Acceptance Test

Software Development Process Waterfall, Incremental, Iterative, Spiral, etc Unified Process Agile development

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 2

Software Application Domains System software Application software Engineering or Scientific Software Embedded software Product-line software (includes entertainment software) Web-Applications Artificial intelligence software

IF3250-Proyek Perangkat Lunak (Informatika ITB) 3

Software Engineering Software engineering is the establishment of sound

engineering principles in order to obtain reliable and efficient software in an economical manner.

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Software engineering encompasses a process, management techniques, technical methods, and the use of tools.


Software Engineering (2)


System Engineering Hierarchy


Business or product domain World View

Domain View

Element View

Detail View

domain of interest

system element

The Product Engineering Hierarchy


The Complete Product

Hardware Software

Data Function Behaviour

Requirement Engineering (World View)

Component Engineering (Domain View)

Analysis and Design modeling

(Element View)

Construction & Integration (Detail View)

capabilities

processing requirement

program component

Requirements Analysis


Requirements’ Gathering

Software Requirements Hardware

Requirements

User Requirements

System/ Technical/ Hardware

Requirements

Business Requirements

and/or Business Rules


Complete Requirements

R1 R2 R3

R1.1 R1.2 R1.3 R2.1 R2.2 R3.1 R3.2 R3.3

Requirements’ Decomposition

Global Design and Detailed Design



R1 R2 R3

R1.1 R1.2 R1.3 R2.1 R2.2 R3.1 R3.2 R3.3

D1.1 D1.2 D1.3 D2.1 D2.2 D3.1 D3.2 D3.3

DD1 DD2 DD3 DD4 DD5 DD6 DD7 DD8 DD9 DD10

From Design to Coding



R1 R2 R3

R1.1 R1.2 R1.3 R2.1 R2.2 R3.1 R3.2 R3.3

D1.1 D1.2 D1.3 D2.1 D2.2 D3.1 D3.2 D3.3


C1 C2 C3 C4 C5 C6 C7 C8 C9 C10

Unit Testing


C1 C2 C3 C4 C5 C6 C7 C8 C9 C10


D1.1 D1.2 D1.3 D2.1 D2.2 D3.1 D3.2 D3.3


R1 R2 R3

R1.1 R1.2 R1.3 R2.1 R2.2 R3.1 R3.2 R3.3

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10

Integration Test1

Integration Test2

Integration Test4

Integration Test3

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10

Integration Test


Package1 Package2 Package3

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10

Package4

Integration Test1

Integration Test2

Integration Test4

Integration Test3

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10

User Acceptance Test


Complete Program

Package1 Package2 Package3

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10

Package4

User Acceptance Test

Software Development Life Cycle


Waterfall Model


Requirement Engineering

Requirement Analysis

Global and Detailed Design

Implementation/ Coding

Deployment

Maintenance

Prototyping Model


Incremental Model



Rapid Application Development Model

Spiral Model



Boehm’s Spiral Model


Concurrent Development Model


Coding

Detailed Design

Global Design

User Requirements

Unit Testing

Integration Testing

User Acceptance Testing

“V” Model

30-Aug-13 SW Dev Methodologies/Bayu Hendradjaya

Component Based Development


Domain Analysis

SW Arch Development

Domain Model

Structural Model

Repository Reusable Artifacts/ Components

Reusable Component Development

Analysis Architectural Design

Component Engineering

Component Qualification

Component Adaptation

Component Composition

Component Update

Testing

Application Software

Component Development

Application Domain Development CBSE

27 IF2036 RPL - IF ITB

The Unified Process Consists of A set of principles A collection of processes to use as a starting point Customizable process framework and knowledge base

Use-case driven, architecture centric, iterative, and incremental software process

Phases Inception phase (customer communication and planning) Elaboration phase (communication and modeling) Construction phase Transition phase (customer delivery and feedback) Production phase (software monitoring and support)


P r e l i m i n a r y I t e r a t i o n ( s )

i t e r . # 1

i t e r . # 2

i t e r . # n

i t e r . # n + 1

i t e r . # n + 2

i t e r . # m

i t e r . # m + 1

I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n

I t e r a t i o n s

P h a s e s C o r e W o r k f l o w s

A n i t e r a t i o n i n t h e e l a b o r a t i o n p h a s e

Requirements

Design

Implementation

Test

Analysis

Iteration and Workflow


Iteration and Workflow


IBM Software Group-Rational Unified Process

Agile Software Development


Agile Manifesto


The items on the left is valued more than the right items.

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Agile Traditional

What is Agile? An iterative and incremental (evolutionary) approach

performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.

Core principles “Fits just right” process Continuous testing and validation Consistent team collaboration Rapid response to change Ongoing customer involvement Frequent delivery of working software


An Agile View of Process

Compromise between Conventional Software Development to a Software Project Represents a reasonable compromise between conventional software

engineering for certain classes of software and certain types of software projects

Deliver a successful system quickly Stresses on Continuous Communication and Collaboration

among developers and customers Embraces a philosophy that encourages:

customer satisfaction, incremental software delivery, small project teams (composed of software engineers and stakeholders), informal methods, and minimal software engineering work products

Stress on-time delivery of an operational software increment over analysis and design


12 Principles Highest priority: user satisfaction Welcome changing requirement Deliver working software frequently Business people and developers work together daily Build around motivated individuals Face-to-face conversation Working software: primary measure of progress Promote sustainable development Continuous attention to technical excellence and good design Simplicity is essential Self-organizing team Tune and adjust team behavior at regular intervals


Challenges in Agile


Agile Development

Co-located

Geographical distribution

Global

Compliance requirement

Low risk Critical, Audited

Application complexity Simple, single platform

Complex, multi-platform

Organization distribution (outsourcing, partnerships)

Team size Under 10 developers

100’s of developers

Degree of Governance

In-house Third party

Informal Formal

Entrenched process, people, and policy

Minimal Significant

Agile Process Models Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM) Agile Unified Process (AUP) Essential Unified Process (EssUP) Open Unified Process (OpenUP) Velocity tracking

* SEPA 6th ed, Roger S. Pressman


Agile Software Development Agile Methodology is develop based on iterative and incremental

development It is based on feedback from the clients. In this methodology the requirements and solutions evolve through

collaboration between self-organizing, cross-functional teams who work in close liaison with the clients.

It promotes evolutionary development, adaptive planning and encourages rapid and flexible response to change.

It is suitable for Product (and less for services) Smaller to medium sized products

Development teams for such products is ranging from 5 to 20-20 members A team of 100 members was also noted to be a success


Agile vs. Other Methodologies The requirements from the client is collected iteratively

and in an evolutionary manner. Each stage, including the requirement analysis stage, needs

to be completed and finalized, before moving on to the next stage.

Less documentation Because of smaller team size, extensive informal

communication makes high quality software development feasible.

But it would be difficult to ensure high quality in larger projects, due to this methodological limitation, which is mostly made by choice to ensure faster delivery of software projects.


Agile Software Development Agile Methodology is develop based on iterative and incremental

development It is based on feedback from the clients. In this methodology the requirements and solutions evolve through

collaboration between self-organizing, cross-functional teams who work in close liaison with the clients.

It promotes evolutionary development, adaptive planning and encourages rapid and flexible response to change.

It is suitable for Product (and less for services) Smaller to medium sized products

Development teams for such products is ranging from 5 to 20-20 members A team of 100 members was also noted to be a success


Two dimensions, four (or more) process styles


Disciplined Well-documented

Traceability Change Control Board

High ceremony

Relaxed Little documentation

Light process Low ceremony

Waterfall Few risk, sequential

Late integration and testing

Iterative Risk driven

Continuous integration and testing

Agile Sweet Spot




High ceremony







Agile Agility at Scale

Unified Process (Rational Unified Process)




High ceremony







OpenUP RUP

“Light”

RUP for large-scale SOA

RUP for Sys Eng

RUP Framework

Common language Common Practices Oversight Flexible resourcing Reuse

Common Difficulties (1) Process Weight and Perfection Too much formality / too many artifacts

Only produce the artifacts that add value, minimize formality if possible

Use informal resources (brief document templates) and not formal resources

When in doubt of value, don’t do it

Analysis Paralysis You can improve upon things later on – move on Focus on phase objectives. E.g. Inception is NOT about describing all

requirements in detail


Common Difficulties (2) Life Cycle Following a waterfall process, versus RUP’s iterative processes

Look beyond a flawed 5-minute perception of what RUP phases are about… Produce working (tested) code every iteration (exception maybe Inception)

Big Upfront Architecture Problem: Complete misunderstanding of what Elaboration is about RUP focuses on rapidly producing an Executable Architecture 10-20% of code, critical capabilities implemented, not a lot of paper design

Save the tricky part for later Attack risks early, or they attack you Hard on you now, but makes life easier later


Common Difficulties (3) Organization and Mentality Functional, Specialized Organization

Teams of generalists and multitasking experts No place for “I only do <X>” mentality

No customer feedback until a late beta Unlikely to build the right product A lot of waste

No willingness to change things Change enables improvement

Your process is stagnant versus evolving Document changes in development case


Common Difficulties (4) Development Approach Functional, Specialized Organization

Teams of generalists and multitasking experts No place for “I only do <X>” mentality

No customer feedback until a late beta Unlikely to build the right product A lot of waste

No willingness to change things Change enables improvement

Your process is stagnant versus evolving Document changes in development case


Unified Process in a Nutshell (case study: OpenUp)


Scrum

Eclipse Way

RUP

RUP

DSDM

RUP

XP

AMDD

Influence

Executing an Iteration (sample)


Iteration planning

Upfront planning and architecture

Stable weekly build Stable iteration build

Continuous micro-increments / bug-fixing / builds

Continuous bug-fixing /

micro-increments / builds

A few hours

A few days

Iteration review / Retrospective

A few hours

Managing Work Items List


High Priority

Low Priority

New work items can be added at any time

Work items can be removed at any time

Work items can be reprioritized at any time

Low-priority work items can be vague

High-priority work items should be well-defined

Work Item List

Each iteration implements the highest-priority work items

Project Life Cycle


Implementing Unified Process using Agile Principles


Agile Development with Rational Unified Process (RUP)


Follow RUP’s agile practices Shared vision Regular delivery of working software Active stakeholder participation Test-Driven Development (TDD) Continuous builds Early and frequent system-level testing Just enough process

Add additional agile practices: Self organization Micro increments managed by work items Iteration Lifecycle (what do you do at what week

within an iteration)

Leverage RUP’s content around agility at scale Guidance on how to deal with complexity drivers

Customize RUP Start with a small out-of-the-box process

RUP for Small Projects / RUP for Maintenance

Customize it to meet your needs Make it smaller by deselecting content packages not needed Remove artifacts not needed (additional support for this in RMC 7.2)

Publish the (delivery) process Choose to publish only the delivery process, versus entire configuration

Leverage Development Case A 1-3 page description of the process you use Reference your RUP process and other sources, no need to duplicate info

Improve the process every iteration Update development case after each iteration review / retrospective Update delivery process if significant changes


Iterative Development Phases


Inception Elaboration Construction Transition

Major Milestones

Inception: Agreement on overall scope Vision, high-level requirements, business case Not detailed requirements

Elaboration: Agreement on design approach and mitigation of major risks Baseline architecture, key capabilities partially implemented Not detailed design

Construction: Agreement on complete operational system Develop a beta release with full functionality

Transition: Validate and implement solution Stakeholder acceptance, cutover to production

Inception: Know What to Build Typically one short iteration Produce vision document and initial business case Only produce what has value

Develop high-level project requirements Initial use-case and (optional) domain models (10-20% complete) Focus on what is required to get agreement on ‘big picture’

Manage project scope Reduce risk by identifying key requirements Acknowledge that requirements will change

Manage change, use iterative process

Produce conceptual prototypes as needed


Example: UCs in Inception Inception: 5 people, 2 weeks (for a 6 month project) => 400 hours

2 hour joint UC workshop with key stakeholders ~10 hours 15 UCs, 4 critical, 5 important, 6 less important

Outline UCs: 4 hours per critical, 2 per important, and 1 per less important ~ 32 Includes some potential UI mockups

UC walkthrough: 1 hour per important UC, 30 min for all others x 5 people ~ 48 hours Focus is on extended team converging on what application they are building, not to lock

down on requirements

Further updates based on walkthrough ~ 10 hours

Discussion: Is it worth to spend ~100 hours on getting concurrence on an initial UC Model? Note – we know the UC model will evolve as project progresses


Elaboration: Know How to Build It by Building Some Elaboration can be a day long or several iterations Balance mitigating key technical and business risks with

producing value (tested code) Detail ~top 3rd most essential requirements (so you can

estimate and prioritize) Produce (and validate) an executable and stable architecture Define, implement and test interfaces of major components. Partially

implement some key components. Identify dependencies on external components and systems. Integrate

shells/proxies of them. Roughly 10% of code is implemented.

Drive architecture with key use cases 20% of use cases drive 80% of the architecture


Construction: Build The Product Incrementally define, design, implement and test more and

more scenarios Incrementally evolve executable architecture to complete

system Evolve architecture as you go along

Frequent demonstrations and partial deployment Partial deployment strategy depends greatly on what system

you build

Daily build with automated build process You may have to have a separate test team if you have Complex test environments Safety or mission critical systems


Transition: Stabilize and Deploy Project moves from focusing on new capabilities to

stabilizing and tuning Produce incremental ‘bug-fix’ releases Update user manuals and deployment documentation Execute cut-over Conduct “post-mortem” project analysis


References Per Kroll, “RUP and Agility at Scale”, A slide presentation

from IBM Software Group Roger Pressman, “Software Engineering: A Practitioner

Approach”, Prentice Hall


Documents

Software Engineering Review - Software Process