software engineering - chp1- software dev methodologies

MedTech

Chapter 1 – Software Development MethodologiesMethods and Methodologies for designing software

Dr. L i l ia SFAXIw w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi

Sl id e 1

MedTech – Mediterranean Institute of TechnologySoftware Engineering

MedTech

MedTech

Summary of the Course

Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi

Sl id e 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…


Sl id e 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


Sl id e 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


Sl id e 5


MedTech



Sl id e 6



• Prototyping

• V-Model

• Spiral


• 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 partia l

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 partia l or final solution• Well defined goals, not all features known, learn-by-doing strategy


Sl id e 7


MedTech

Sw. Dev. Models : Incremental vs. Iterative


Sl id e 8


MedTech

Sw. Dev. Models : Incremental and Iterative


Sl id e 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


Sl id e 10


MedTech



Sl id e 11



• Prototyping

• V-Model

• Spiral


• 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


Sl id e 12

Software Development Methodologies

MedTech

Waterfall

Analysis

Design

Development

Testing

Implementation

Maintenance


Sl id e 13

Software Development Methodologies• Linear Model

• Requirement should be clear before the next step

• Testing is done once the code fully developed

• A time period is defined for each step

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


Sl id e 14


MedTech

Prototyping


Sl id e 15


MedTech

Prototyping


Sl id e 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


Sl id e 17


Analysis

HighLevelDesign

Low LevelDesign

Implementation

AcceptanceTesting

SystemTesting

IntegrationTesting

UnitTesting

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


Sl id e 18


MedTech

Spiral


Sl id e 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


Sl id e 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


Sl id e 21


MedTech



Sl id e 22


MedTech


• Pros• Reduced development time

• Increased reusability of components

• Quick initia l 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


Sl id e 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


Sl id e 24


MedTech

Unified Process


Sl id e 25


MedTech

Unified Process : Terminology


Sl id e 26

Software Development Methodologies• Development Cycle

• Period of time that elapses from the start of the project until product release• Artifact

• Piece of information produced, modif ied 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-def ined 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 visio n do cument• Optio nal business mo del• In itial pro ject glo ssary

• Identify key system functionality• An initial use case mo del (10-20% co mplete)• One o r several pro to types

• Understand costs, schedule and risks• Decide what process to fo llow and what tools to use

• Pro ject plan

• First Major Milestone: Lifecyle Objective Milestone• Is the project doomed to fail?


Sl id e 27


MedTech


• Elaboration : 30% Time, 20% Effort• Define and baseline the architecture of theSystem to provide a stable basis for the design• Deeper requirements understanding

• At least 80% co mplete use case mo del• No n functio nal requirements captur ing

• Architect consideration• So ftware architecture descr iptio n• Executable architectural pro to type

• Revised risk list and business case• Development case ref inement

• Co arse grained pro ject plan• Defining iteratio ns & evaluatio n cr iter ia fo r each o ne

• Major Milestone: Lifecycle Architecture• Is the project’s plane, vision, architecture are good enough to achieve project

goals?


Sl id e 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.?


Sl id e 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?


Sl id e 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


Sl id e 31


MedTech



Sl id e 32


Capture of Business requirements

Analysis

Capture of Technicalrequirements

Generic Design

Preliminary Design

Detailed Design

Coding and Tests

Recipe

Functional Branch Technical Branch

Design and Development Branch

MedTech



Sl id e 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 whichthe 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


Sl id e 34


MedTech

Agile Manifesto : agilemanifesto.org


Sl id e 35


Through this work, we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding 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 throughoutthe 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.


Sl id e 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 ableto 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--isessential.

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.


Sl id e 37


MedTech

Agile Approach


Sl id e 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


Sl id e 39


MedTech


• Key principles3. Designing

• Simplicity• Choose a system metaphor• Never add functionalities early• Refactor whenever and wherever possible

4. Coding• Customer a lways available• Code the unit test first• All production code is pa ir 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


Sl id e 40


MedTech



Sl id e 41


MedTech

SCRUM

A little story to kick it off


Sl id e 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 whathas to be done, they know (most of the times) what they need.


Sl id e 43


MedTech

SCRUM

• A product owner creates a priorit ized 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 t ime — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess itsprogress (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.


Sl id e 44


MedTech

SCRUM


Sl id e 45


MedTech

References


Sl id e 46

• A.U. Hakizabera and al. L inear Models vs Agile Models: Making the r ight model decision, 2010

• S. Balaj i and al. WATEERFALL Vs V-MODEL Vs AGILE: A COMPARATIVE STUDY ON SDLC, JITBM, 2012

• N. Munassar and al. A Comparison Between F ive Models Of Software Engineer ing, IJCSI, 2010

• M. Kalali, RUP Overview, 2004

• K. Beck, Extreme Programming Explained, 2000