Upload
sarahasanayaz12345
View
5
Download
2
Tags:
Embed Size (px)
Citation preview
Software Process Models• Prescriptive Process Models
1. Waterfall model (Royce, 1970)• V-Model: The V-model depicts the relationship of quality assurance
actions to the actions associated with the different step of waterfall model
2. Incremental Process Models3. Evolutionary Process Models
• Prototyping• Spiral model (Boehm, 1988)
4. Concurrent Models
• Specialized Process Models1. Component Based Development2. The Formal Methods Model3. The Unified Process Model
08.10.2011 Dr. S. N Ahsan, IQRA-University 4
‘Rules of Thumb’ about approach to be used
IF uncertainty is highTHEN use evolutionary approach
5
IF complexity is high but uncertainty is notTHEN use incremental approach
IF uncertainty and complexity both lowTHEN use one-shot
IF schedule is tightTHEN use evolutionary or incremental
Specialized Process Models
Component based Development:
The process to apply when reuse is a development objective Unified Process:
A “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
Formal methods:
Emphasizes the mathematical specification of requirements
SWE 418 (062) Software Process Models 6
Component Based DevelopmentCOTS or Commercial Off-The-Shelf components are becoming more available. Most (not all) COTS components have targeted functionality with good interfaces that enable the component to be integrated.
Examples:
Software:
• Operating Systems (UNIX, Windows/NT, OS2)
• Databases (Oracle, Sybase)
• Graphics Packages (Motif, ??)
Hardware:
• Processors (Motorola, HP, Sun, Intel)
• Disk Drives (Western Digital, Red Rock)
• Peripherals (Printers, Monitors, Keyboards, etc.)
08.10.2011 Dr. S. N Ahsan, IQRA-University 7
Unified Process Models
• A “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
08.10.2011Dr. S. N Ahsan, IQRA-
University8
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
Agile Development
• Agile Software Engineering combines a philosophy and a set of development guidelines. – The philosophy encourages customer satisfaction and
early incremental delivery of software,
– Small highly motivated project teams
– Informal method
– Minimal Software Engineering work products
– Development simplicity
• What is Agility?
– Quick and effective response to change
9
XP Practices (1-12)
1. Planning game2. Small releases3. Metaphor4. Simple design5. Testing6. Refactoring7. Pair-programming7. Collective ownership8. Continuous integration9. 40-hour week10. On-site customer11. Coding standards
19.04.23 Dr. S. Nadeem Ahsan, IQRA-University 10
Refactoring
Refactoring: changes to the organization of a program, not its function. Behavior preserving program transformations.
Why Refactoring is Important: Only defense against software decay. Often needed to fix reusability bugs. Lets you add patterns after you have written a program; lets you
transform program into framework. Lets you worry about generality tomorrow; just get it working today.
Pair Programming: Experience the Difference
Laurie Williams
North Carolina State University
Robert Kessler
University of Utah
Pair Programming Driver and Navigator working together on one task Roles changing often. Collective responsibility for outcome. Bringing together of multiple perspectives, experiences, abilities, and
expertise
Why Pair:
– Higher quality code
– Faster cycle time
– Enhanced trust/teamwork
– Knowledge transfer
– Enhanced learning
– More fun
Post Development Test Cases Passed
0.0%10.0%20.0%30.0%40.0%50.0%60.0%70.0%80.0%90.0%
100.0%
Program 1 Program 2 Program 3 Program 4
Individuals
Collaborators
Elapsed Time
0.0%
20.0%
40.0%
60.0%
80.0%
100.0%
120.0%
Program 1 Program 2 Program 3
One Individual One Collaborator
Pair Programming: A Historical Perspective
. . . 1995
1996 1997 1998 1999
2000
2001
Hill Air Force Base:
“Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm . . .
The error rate through software-system integration was three orders of magnitude lower than the organization's norm . . .
A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walkthroughs, mentoring and motivation.”
Formal Method
Formal methods allow a software engineer to create a specification that is more complete, consistent, and unambiguous than those produced using conventional or object oriented methods. • Set theory and logic notation are used to create a clear statement of
facts (requirements).
• This mathematical specification can then be analyzed to prove correctness and consistency.
• Because the specification is created using mathematical notation, it is inherently less ambiguous than informal modes of representation.
08.10.2011 Dr. S. N Ahsan, IQRA-University 19
What is Formal Methods?
Formal methods = Formal Specification
+
Refinement
+
Formal Verification
Set theory, logics, algebra, etc.
Formal Specification and Verification
• Formal methods can be applied at various points through the development process
– Specification
– Verification
• Specification: Give a description of the system to be developed, and its properties
• Verification: Prove or disprove the correctness of a system with respect to the formal specification or property
Specification
• Formal methods for specification of the concurrent systems
– CSP (Hoare 1985)
– Temporal Logic (Pnueli 1981)
– I/O Automata (Lynch and Tuttle 1987)
Verification
• Two well established approaches to verification
– Model Checking
– Theorem Proving
• Model checking
– Build a finite model of system and perform an exhaustive search
• Theorem Proving
– Mechanization of a logical proof
Example of Formal Specification
• Consider the following constructive specification example:
• The specification has three components
1. A signature
2. A Predicate (a boolean expression)
3. Terms n
• Another example :
08.10.2011 Dr. S. N Ahsan, IQRA-University 24
Coupling and Cohesion
Characteristics of Good Design: High cohesion Low coupling
No dependencies Loosely coupled-some dependencies
High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.
Cohesion: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component.
Coupling:
Programming Paradigms Procedural programming
Executing a set of commands in a given sequence Fortran, C, Cobol
Functional programming Evaluating a function defined in terms of other functions Lisp, ML, OCaml
Logic programming Proving a theorem by finding values for the free variables Prolog
Object-oriented programming (OOP) Organizing a set of objects, each with its own set of responsibilities Smalltalk, Java, C++ (to some extent)
Aspect-oriented programming (AOP) Executing code whenever a program shows certain behaviors AspectJ (a Java extension) Does not replace O-O programming, but rather complements it
28
Aspect Oriented Programming
Aspect Oriented Programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.
AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while "aspect-oriented software development" refers to a whole engineering discipline.
08.10.2011 Dr. S. N Ahsan, IQRA-University 29
Crosscutting Concerns• AOP addresses behaviors that span many, often
unrelated, modules.– Core Concerns:
• Primary core functionality.• Central functionality of a module.
– Crosscutting Concerns:• System wide concerns that span multiple modules.• Cuts across the typical division of responsibility.
– OOP creates a coupling between core and crosscutting concerns.
– AOP aims to modularize crosscutting concerns.
08.10.2011 Dr. S. N Ahsan, IQRA-University 30
Aspects
• In AOP crosscutting concerns are implemented in aspects instead of fusing them into core modules.
• Aspects are an additional unit of modularity.
• Aspects can be reused.
• By reducing code tangling it makes it easier to understand what the core functionality of a module is.
• An “aspect weaver” takes the aspects and the core modules and composes the final system.
08.10.2011 Dr. S. N Ahsan, IQRA-University 31
Terminology cont
• Core concerns– Central functionality of a Business logic (single module)– Customer and Account management, Interbanking
transactions, ATM transactions• Crosscut concerns
– System-level, peripheral requirements (multiple modules)– Persistence of all entities, Transaction integrity,
Authorization of access to various services, logging, Security, Error checking, Policy enforcement
19 August 2005 Aspect Oriented Programming 32
AOP Methodology
• The idea behind AOP is “Separation of concern”
• AOP builds upon Existing Methodologies (OOP, Procedural programming), augmenting them with concepts and constructs in order to modularize crosscutting concerns.
• Now, concern consists of what?
19 August 2005 Aspect Oriented Programming 33
AOP Methodology
Software Application
• Procurement Management System
• Human Resource Management Package
• PLC based Industrial Control System
39
A Good Manager Measures
measurementmeasurement
What do weWhat do weuse as ause as abasis?basis? • • size?size? • • function?function?
project metricsproject metrics
process metricsprocess metricsprocessprocess
productproduct
product metricsproduct metrics
40
Why Do We Measure?
• assess the status of an ongoing project
• track potential risks
• uncover problem areas before they go “critical,”
• adjust work flow or tasks,
• evaluate the project team’s ability to control quality of software work products.
Measure, Measurement and Metrics• A measure provides a quantitative indication of the
extent, amount, dimension, capacity, or size of some attribute of a product or process.
• Measurement is the act of determining a measure. Example: the number of errors in a system is a measurement.
• A Metric is a measurement of the degree that any attribute belongs to a system, product or process. Example: the number of errors per person hours would be a metric.
Why Measure Software?
• Determine the quality of the current product/process/project
• Predict qualities of a product/process/project
• Improve quality of a product/process/project
• Assess the status of an ongoing project & track potential risks
Metric Classification
1. Products Metrics:I. Size Metrics (LOC and Function Points)II. Halstead’s Product Metrics III. Complexity Metrics
2. Object Oriented Metrics3. Processes4. Project
Product MetricsSize Metrics: LOC Metrics
• Size of the software produced
• LOC - Lines Of Code
• KLOC - 1000 Lines Of Code
• SLOC – Statement Lines of Code (ignore whitespace)
• Typical Measures:
– Errors/KLOC, Defects/KLOC, Cost/LOC, Documentation Pages/KLOC
Size Metrics: Function Point Metrics
A conceptual measure of software size based on functional requirements
– Basis is the measured proportions of effort required to produce types of functionality
•Function Point: A measure which represents the functional size of application
•Function Point Analysis: A standard method for measuring software development and maintenance from the customer’s point of view.
•Function Point Count: The function point measurement of a particular application or project
FP = count total × [0.65+0.01 × Σ(Fj)]
Function Point Metrics
• Using FPA to help manage a software project can improve the probability of completing a project
Evaluating the Economics of a Project
One software project, coded in 3-different languagesOne software project, coded in 3-different languagesSLOC metrics can be misleadingSLOC metrics can be misleading
19.04.23 Dr. S. Nadeem Ahsan, IQRA-University 50
Function Point Metrics are Comparable and Logical across Projects , Platform and Languages