Software Engineering Review - Software Process
-
Upload
ikmal-syifai -
Category
Documents
-
view
49 -
download
5
description
Transcript of 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.
IF3250-Proyek Perangkat Lunak (Informatika ITB) 4
Software Engineering (2)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 5
System Engineering Hierarchy
IF3250-Proyek Perangkat Lunak (Informatika ITB) 6
Business or product domain World View
Domain View
Element View
Detail View
domain of interest
system element
The Product Engineering Hierarchy
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 7
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
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 10
Requirements’ Gathering
Software Requirements Hardware
Requirements
User Requirements
System/ Technical/ Hardware
Requirements
Business Requirements
and/or Business Rules
IF3250-Proyek Perangkat Lunak (Informatika ITB) 11
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 12
Complete Requirements
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
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 13
Complete Requirements
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
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
Unit Testing
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 14
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
DD1 DD2 DD3 DD4 DD5 DD6 DD7 DD8 DD9 DD10
D1.1 D1.2 D1.3 D2.1 D2.2 D3.1 D3.2 D3.3
Complete Requirements
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
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 15
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
IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya 16
Complete Program
Package1 Package2 Package3
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
Package4
User Acceptance Test
Software Development Life Cycle
IF3250-Proyek Perangkat Lunak (Informatika ITB) 17
Waterfall Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 18
Requirement Engineering
Requirement Analysis
Global and Detailed Design
Implementation/ Coding
Deployment
Maintenance
Prototyping Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 19
Incremental Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 20
IF3250-Proyek Perangkat Lunak (Informatika ITB) 21
Rapid Application Development Model
Spiral Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 22
IF3250-Proyek Perangkat Lunak (Informatika ITB) 23
Boehm’s Spiral Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 24
Concurrent Development Model
IF3250-Proyek Perangkat Lunak (Informatika ITB) 25
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 26
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)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 28
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
29 IF2036 RPL - IF ITB
Iteration and Workflow
IF3250-Proyek Perangkat Lunak (Informatika ITB) 30
IBM Software Group-Rational Unified Process
Agile Software Development
IF3250-Proyek Perangkat Lunak (Informatika ITB) 31
Agile Manifesto
32 IF2036 RPL - IF ITB
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 33
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
34 IF2036 RPL - IF ITB
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
35 IF2036 RPL - IF ITB
Challenges in Agile
IF3250-Proyek Perangkat Lunak (Informatika ITB) 36
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
37 IF2036 RPL - IF ITB
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 38
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.
IF3250-Proyek Perangkat Lunak (Informatika ITB) 40
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 41
Two dimensions, four (or more) process styles
IF3250-Proyek Perangkat Lunak (Informatika ITB) 42
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 43
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 Agility at Scale
Unified Process (Rational Unified Process)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 44
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
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 45
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 46
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 47
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 48
Unified Process in a Nutshell (case study: OpenUp)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 49
Scrum
Eclipse Way
RUP
RUP
DSDM
RUP
XP
AMDD
Influence
Executing an Iteration (sample)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 50
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 51
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 52
Implementing Unified Process using Agile Principles
IF3250-Proyek Perangkat Lunak (Informatika ITB) 53
Agile Development with Rational Unified Process (RUP)
IF3250-Proyek Perangkat Lunak (Informatika ITB) 54
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 55
Iterative Development Phases
IF3250-Proyek Perangkat Lunak (Informatika ITB) 56
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 57
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 58
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 59
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 60
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
IF3250-Proyek Perangkat Lunak (Informatika ITB) 61
References Per Kroll, “RUP and Agility at Scale”, A slide presentation
from IBM Software Group Roger Pressman, “Software Engineering: A Practitioner
Approach”, Prentice Hall
IF3250-Proyek Perangkat Lunak (Informatika ITB) 62