Software Engineering - chp1- software dev methodologies

MedTech
Chapter 1 – Software Development
Methodologies
Methods and Methodologies for designing software
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
MedTech – Mediterranean Institute of Technology
Software Engineering
MedTech

MedTech
Summary of the Course
Dr. Lilia SFAXI
Slide 2
• Introduction to Software Development Methodoogies
• Software Development Models
• Software Development Methodologies
• Ad-hoc
• Waterfall
• Prototyping
• V-Model
• Spiral
• RAD
• Unified Process
• Agile

MedTech
Software Project
• A project is a set of actions planned and executed by a group of
people in order to reach a goal, limited by a deadline, and having a
certain cost
• To manage a project
• Define a methodology
• Manage concerned people
• Manage technical constraints
• Manage available means…
Dr. Lilia SFAXI
Slide 3
Introduction to Software Development Methodologies

MedTech
Software Development Methodology
• Also called:
• System Development Methodology
• Software Development Lifecycle
• Software Development Process
• A set f activities whose goal is the development or evolution of
software
• Generic activities in all software processes
• Specification
• Design
• Development
• Validation
• Evolution
Dr. Lilia SFAXI
Slide 4

MedTech
Software Lifecycle
• Defines all the software development phases, starting from the
requirements specification of the client, to the final stages of
software creation
• These phases are organized with regard to models that guide the
engineer in his activities
• Linear models
• Iterative models
• Incremental models
• Adaptive models
• Extreme models
Dr. Lilia SFAXI
Slide 5

MedTech
Dr. Lilia SFAXI
Slide 6
• Ad-hoc
• Waterfall
• Prototyping
• V-Model
• Spiral
• RAD
• Unified Process
• Agile

MedTech
Software Development Models
• Linear Model
• A number of dependent phases that are executed in a sequential order
with no feedback loops
• The solution is only produced at the final phase
• Well defined goals, requirements and solution, few scope change requests
• Incremental Model
• Same as the linear model, except that each phase releases a partial
solution or deliverable
• Well defined goals, requirements and solution, more agressive schedule
• Iterative Model
• A number of phases repeated in groups with a feedback loop after each
group is completed
• The last phase in a group might release a partial or final solution
• Well defined goals, not all features known, learn-by-doing strategy
Dr. Lilia SFAXI
Slide 7

MedTech
Sw. Dev. Models : Incremental vs. Iterative
Dr. Lilia SFAXI
Slide 8

MedTech
Sw. Dev. Models : Incremental and Iterative
Dr. Lilia SFAXI
Slide 9

MedTech
Software Development Models
• Adaptive Model
• Progresses from iteration to iteration based on limited specification of the
solution
• Each iteration learns from the preceding ones
• Attempts to converge on an acceptable solution for the customer
• Well defined goals but frequent change requests
• Extreme Model
• Same as the adaptive model except that the specification of the solution is
minimal and the goals are not clearly defined
• Goals are unknown, typical R&D projects
Dr. Lilia SFAXI
Slide 10

MedTech
Dr. Lilia SFAXI
Slide 11
• Ad-hoc
• Waterfall
• Prototyping
• V-Model
• Spiral
• RAD
• Unified Process
• Agile

MedTech
Ad-hoc (Big Bang) Methodology
• Typically, no methodology at all!
• The client states his needs, and the developer
just does the work!
• Pros
• Simple and straightforward
• Adequate for small and simple systems
• Cons: A big problem if:
• The client doesn’t express his needs correctly
• The developer doesn’t know how to proceed with the implementation
• … and it does not support any changes in the requirements
Dr. Lilia SFAXI
Slide 12
Software Development Methodologies

MedTech
Waterfall
Analysis
Design
Development
Testing
Implementation
Maintenance
Dr. Lilia SFAXI
Slide 13
• Linear Model
• Requirementshould be clear before the next step
• Testing is done once the code fully developed
• A time period is defined for eachstep

MedTech
Waterfall
• Pros
• Requirement is clear before development starts
• Each phase is completed in specific period of time, after that it moves to
the next phase
• As a linea model, it is easy to implement
• The amount of required resources are minimal
• Each phase requires a proper documentation
• Cons
• Some phases problems appear when going through the next phases
• It is not flexible and does not support any requirements changes
• The client sees the resulting product once all the phases are over
Dr. Lilia SFAXI
Slide 14

MedTech
Prototyping
Dr. Lilia SFAXI
Slide 15

MedTech
Prototyping
Dr. Lilia SFAXI
Slide 16
• Remedies to the problem of the waterfall methodology, where we are
never sure if the specification will work until you are at the last stage
• Creates a prototype of the application:
• Incomplete versions of the program
• Simulates only a few aspects of the final product
• Pros
• The customer can be reassured with a sample of his application way before
the development is achieved
• Cons
• A prototype mostly cannot cover all the problems a real application does!
• You spend a significant time creating the prototype
• Sometimes, the customer is happy with the prototype, and doesn’t go
further with the real application!!

MedTech
V-Model
Dr. Lilia SFAXI
Slide 17
Analysis
High Level
Design
Low Level
Design
Implementation
Acceptance
Testing
System Testing
Integration
Testing
Unit Testing

MedTech
V-Model
• Modified version of the waterfall method (linear model)
• The stages turn back upwards to verify and validate every step
• The test cases are prepared with every step
• Tester et developer work in parallel
• Pros
• Same as those of the waterfall + the tester is involved from the
requirement phase
• Cons
• Rigid
• If changes happen midway, not only the requirements documentation, but
also the test documentation need to be changed
• Is not adequate for short term projects as it requires reviews at each stage
Dr. Lilia SFAXI
Slide 18

MedTech
Spiral
Dr. Lilia SFAXI
Slide 19

MedTech
Spiral
• Linear and Incremental Model + Prototyping
• Big emphasis on risk assessment
• 4 main phases:
• Objective Setting, Risk Analysis, Engineering and Planning
• Pros
• High amount of risk analysis
• Software produced early in the lifecycle
• Cons
• Can be costly
• Risk analysis requires highly specific expertise
• Is not adequate for small projects
Dr. Lilia SFAXI
Slide 20

MedTech
RAD: Rapid Application Development
• First method that fundamentally breaks with the waterfall-based methods
• Iterative, incremental and adaptative
• Uses minimal planning in favor of rapid prototyping
• Massive use of computarized development tools (CASE, GUI builders, DBMS…)
• Gathers customer requirements through:
• Workshops or focus groups
• Early testing of the prototypes using iterative concept
• Reuse of existing prototypes
• Continuous integration
• Used if:
• There is a need to produce the system in a short span of time (2-3 months)
• There is a high availabilityof designers and a high budget for code generating
tools
Dr. Lilia SFAXI
Slide 21

MedTech
Dr. Lilia SFAXI
Slide 22

MedTech
• Pros
• Reduced development time
• Increased reusability of components
• Quick initial reviews
• Encourages customer feedback
• Iteration time can be short using RAD tools
• Cons
• Depends on a strong team and individual performance
• Only applicable for modularizable systems
• Inapplicable to cheaper projects as cost of modeling and automated code
generation is very high
Dr. Lilia SFAXI
Slide 23

MedTech
Unified Process
• Iterative and incremental model, use case driven and architecture
centered
• A software engineering process based on best practices in software
development
• A disciplines approach to assigning and managing tasks and
responsabilities in a development organization
• Focused on high-quality software that meets the needs of its end users
• Uses the UML notation
• Consists of five core workflows and four phases
Dr. Lilia SFAXI
Slide 24

MedTech
Unified Process
Dr. Lilia SFAXI
Slide 25

MedTech
Unified Process : Terminology
Dr. Lilia SFAXI
Slide 26
• Development Cycle
• Period of time that elapses from the start of the project until product release
• Artifact
• Piece of information produced, modified or used by a process
• Workflow
• Sequence of activities that produces a result of observable value
• Phase
• Each cycle is broken down into a sequence of four phases
• Time during which a well-defined set of objectives is met, artifacts are
completed and decisions whether to move to the next step or not are made
• Iteration
• Inside eahc phase, there may be one or more iterations
• Software is developed in each iteration, concluded by a minor milestone
• The software product grows incrementally as you iterate over the activities
• Milestone
• Release point at which an iteration formally ends

MedTech
Unified Process : Phases
• Inception: 10% Time, 5% Effort
• Helps determine the project feasibility,
what the customer wants and how to get there
• Understand what to build
• A vision document
• Optional business model
• Initial project glossary
• Identify key system functionality
• An initial use case model (10-20% complete)
• One or several prototypes
• Understand costs, schedule and risks
• Decide what process to follow and what tools to use
• Project plan
• First Major Milestone: Lifecyle Objective Milestone
• Is the project doomed to fail?
Dr. Lilia SFAXI
Slide 27

MedTech
• Elaboration : 30% Time, 20% Effort
• Define and baseline the architecture of the
System to provide a stable basis for the design
• Deeper requirements understanding
• At least 80% complete use case model
• Non functional requirements capturing
• Architect consideration
• Software architecture description
• Executable architectural prototype
• Revised risk list and business case
• Development case refinement
• Coarse grained project plan
• Defining iterations & evaluation criteria for each one
• Major Milestone: Lifecycle Architecture
• Is the project’s plane, vision, architecture are good enough to achieve project
goals?
Dr. Lilia SFAXI
Slide 28

MedTech
• Construction: 50% Time, 65% Effort
• Targets a cost-efficient development of a
complete product
• Minimize development costs and achieve
some degree of parallelism
• Iteratively develop a complete product
• Software product integrated on the adequate
platforms
• User manuals
• Desciption of the current release
• Major Milestone: Initial Operational Capability
• Is the product ready to be deployed to a beta test env.?
Dr. Lilia SFAXI
Slide 29

MedTech
• Transition: 10% Time, 30% Effort
• Transition the software product to the user
community
• Think about next releases, finish postponed
features
• Beta testing to validate the new system
against user experience
• Conversion of operational databases
• Training of users and maintainers
• Marketing, distribution
• Improve performance
• Major Milestone: Product Release
• Are the objectives met and should we start another development cycle?
Dr. Lilia SFAXI
Slide 30

MedTech
Two Track Unified Process
• Declination of the Unified Process Methodology
• Takes into account the continuous contraints changes during the
development
• Considers two risks:
• Functional inaccuracy: inadequacy to the requirements
• Unability to integrate technologies
• General principle
• Every possible evolution of the system can be decomposed and managed
separately, following a functional axis and a technical axis
• 2TUP
• Unified process (iterative, archi-centered and UC driven)
• Two branches (technical and functional), merged into a realization branch
Dr. Lilia SFAXI
Slide 31

MedTech
Dr. Lilia SFAXI
Slide 32
Capture ofBusiness
requirements
Analysis
Capture ofTechnical
requirements
Generic Design
Preliminary Design
Detailed Design
Coding and Tests
Recipe
Functional Branch Technical Branch
Design and Development Branch

MedTech
Dr. Lilia SFAXI
Slide 33

MedTech
Agile Approach
• Agile movement seeks alternatives to traditional project management
• Uses the incremental and iterative model
• Regular cadences of work (sprints or iterations) at the end of which
the team must present a product increment
• Every aspect of development (requirements, design, …) is continually
revisited throughout the lifecycle
• Possible changes of direction while the project is running: Agility!
• Inspect-and-adapt approach
Dr. Lilia SFAXI
Slide 34

MedTech
Agile Manifesto : agilemanifesto.org
Dr. Lilia SFAXI
Slide 35
Through this work, we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more

MedTech
Agile Approach : 12 Principles
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, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support their 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.
Dr. Lilia SFAXI
Slide 36

MedTech
Agile Approach : 12 Principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is
essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Dr. Lilia SFAXI
Slide 37

MedTech
Agile Approach
Dr. Lilia SFAXI
Slide 38

MedTech
Extreme Programming (XP)
• Is an Agile Methodology
• Iterative, Incremental and Extreme
• Key principles (see http://www.extremeprogramming.org/ )
1. Planning
• User stories are written
• Release planning creates the release schedule
• Divide the project iterations and start each one with a planning step
2. Managing
• Give the team a dedicated workspace
• Set a sustainable pace
• A stand up meeting starts each day
• The project velocity is measured
• Move people around
• Fix XP when it breaks
Dr. Lilia SFAXI
Slide 39

MedTech
• Key principles
3. Designing
• Simplicity
• Choose a system metaphor
• Never add functionalities early
• Refactor whenever and wherever possible
4. Coding
• Customer always available
• Code the unit test first
• All production code is pair programmed
• Integrate often, with a dedicated computer
5. Testing
• All code must have unit tests, and must pass them before it is released
• When a bug is found, tests are created
• Acceptance tests are run often and the score is published
Dr. Lilia SFAXI
Slide 40

MedTech
Dr. Lilia SFAXI
Slide 41

MedTech
SCRUM
A little story to kick it off
Dr. Lilia SFAXI
Slide 42

MedTech
SCRUM
• Agile Methodology
• SCRUM is a team pack in Rugby, everybody in the pack acts together
with everyone else to move the ball down the field
• A framework for complex software development projects (but not
only…)
• Actors:
• The Scrum Master: is responsible to deliver the expected deliverables. Know
how to get things done.
• The Product Owner: represent stakeholders in meetings. Know what has to
get done. Can prioritize.
• The Team: includes (but is not limited to) developers. They commit to
deliver.
• The Stakeholders: are the sponsor of the project. They might not know what
has to be done, they know (most of the times) what they need.
Dr. Lilia SFAXI
Slide 43

MedTech
SCRUM
• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that
wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four
weeks) — to complete its work, but it meets each day to assess its
progress (daily Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to
hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again.
Dr. Lilia SFAXI
Slide 44

MedTech
SCRUM
Dr. Lilia SFAXI
Slide 45

MedTech
References
Dr. Lilia SFAXI
Slide 46
• A.U. Hakizabera and al. Linear Models vs Agile Models: Making the right model
decision, 2010
• S. Balaji and al. WATEERFALL Vs V-MODEL Vs AGILE: A COMPARATIVE STUDY ON SDLC,
JITBM, 2012
• N. Munassar and al. A Comparison Between Five Models Of Software Engineering,
IJCSI, 2010
• M. Kalali, RUP Overview, 2004
• K. Beck, Extreme Programming Explained, 2000

Software Engineering - chp1- software dev methodologies

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Software Engineering - chp1- software dev methodologies

Similar a Software Engineering - chp1- software dev methodologies (20)

Más de Lilia Sfaxi

Más de Lilia Sfaxi (20)

Último

Último (20)

Software Engineering - chp1- software dev methodologies