Software Engineering: Dr. S. N Ahsan

Software Engineering
BS (Computer Science)
Lecture-03
Date: 25-02-2012
Dr. S. N Ahsan
1
1. 2.
Software Construction Software Management
08.10.2011
Dr. S. N Ahsan, IQRA-University
Quality Focus Process Methods Tools
08.10.2011
Software Common Process Framework
A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity.
08.10.2011 Dr. S. N Ahsan, IQRA-University 4
A Generic Process Framework

1. 2. 3. 4. 5.
Communication Planning Modeling Construction Deployment
08.10.2011
Umbrella Activities
1. 2. 3. 4. 5. 6. 7. 8.
Software Project Tracking and Control Risk Management Software Quality Assurance Technical Reviews Measurements Software Configuration Management Reusability Management Work Product Preparation and Production
Process Flow
Linear Process Flow 2. Iterative Process Flow 3. Evolutionary Process Flow 4. Parallel Process Flow
1.
08.10.2011
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. 3.
Incremental Process Models Evolutionary Process Models

Prototyping Spiral model (Boehm, 1988)
4.
Concurrent Models Component Based Development The Formal Methods Model Aspect Oriented Software Development
Specialized Process Models

1. 2. 3.
The Unified Process

PRESCRIPTIVE-MODEL
Prescriptive Process Models
Developed to bring order and structure to the software development process. To get away from the chaos of most development processes. But there is a strong balance between order and chaos. Absolute order means absence of variability. Absolute chaos makes coordination and coherence impossible. Thus, a balance is needed.
Waterfall Model
Requirements
Design
Implementation
Testing
Maintenance
08.10.2011
11
Waterfall Strengths

Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule
08.10.2011
12
Waterfall Deficiencies

All requirements must be known upfront The following phase should not start until the previous phase has finished. Deliverables created for each phase are considered frozen inhibits flexibility Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
08.10.2011
13
When to use the Waterfall Model

Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.
08.10.2011
14
V-Shaped SDLC Model
A variant of the Waterfall that emphasizes the verification and validation of the product. Testing of the product is planned in parallel with a corresponding phase of development
08.10.2011
15
V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use
08.10.2011
16
V-Shaped Weaknesses
Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements
08.10.2011
17
When to use the V-Shaped Model
Excellent choice for systems requiring high reliability hospital patient control applications All requirements are known up-front When it can be modified to handle changing requirements beyond analysis phase Solution and technology are known
08.10.2011
18
Incremental Development Model
08.10.2011
19
Incremental Model Strengths

Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses divide and conquer breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced
08.10.2011
20
Incremental Model Weaknesses
Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower
08.10.2011
21
When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology
08.10.2011
22
RAD Model
Rapid Application Development an incremental model that emphasizes a short development cycle. Uses component-based construction method. Does not work for all projects particularly large projects or when project is high risk.
08.10.2011
23
RAD Strengths

Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle, minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code (WYSIWYG). Uses modeling concepts to capture information about business, data, and processes.
08.10.2011
24
RAD Weaknesses

Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
08.10.2011
25
When to use RAD

Reasonably well-known requirements User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized
08.10.2011
26
Evolutionary Process Models
Software evolves over time (web pages are a prime example) Limited version is needed to meet business pressures. Time does not allow a full and complete system to be developed. Evolutionary models are iterative as software engineers develop increasingly more complete and complex systems
08.10.2011
27
Prototyping (Evolutionary Model)
Prototypes are built when goals are general and not specific. Prototyping can be used as a standalone process or by one of the processes presented. The prototype serves as the first system. Users get a feel for the actual system and devleopers get something built quickly. A prototype is intended for short term use but too often they are used much longer.
08.10.2011
28
Prototyping (Evolutionary Model)

Requirements
Design Design Implementation Implementation Testing Testing Maintenance
08.10.2011
29
Prototyping Strengths

Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality
08.10.2011
30
Prototyping Weaknesses

Tendency to abandon structured program development for code-and-fix development Bad reputation for quick-and-dirty methods Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)
08.10.2011
31
When to use Prototyping

Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall model Develop user interfaces Short-lived demonstrations New, original development With the analysis and design portions of objectoriented development.
08.10.2011
32
The Spiral Model
An evolutionary model that couples the iterative nature of prototyping with the controlled, systematic aspects of waterfall model. Spiral model is often developed in a series of releases or versions. Is Adobe or Microsoft working on new releases? Better for large projects.
08.10.2011
33
Spiral Model (Evolutionary Model)
08.10.2011
34
Spiral Model (Evolutionary Model)

Determine objectives alternatives and constraints Risk analysis Risk analysis Risk analysis Prototype 3 Prototype 2 Operational protoype Evaluate alternatives identify, resolve risks
REVIEW Requirements plan Life-cycle plan
Risk anal y sis Prototype 1 Concept of Operation
Simulations, models, benchmarks S/W requirements Product design
Development plan Integration and test plan
Plan next phase
Code Unit test Design V&V Integr ation test Acceptance test Develop, verify Service next-level product
Requirement validation
Detailed design
Spiral Model Strengths

Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently
Spiral Model Weaknesses

Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during nondevelopment phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)
08.10.2011
38
SPECIALIZED PROCESS MODELS
39
Component Based Development
COTS 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. This approach incorporates many of the aspects of the spiral model.
08.10.2011
40
Formal Methods Development Model
Formal mathematical specification of the software. Specify, develop and verify by rigourous math notation. Eliminates ambiguity, incompleteness, and inconsistency. Used more where safety-critical software is developed, e.g., aircraft avionics, medical devices, etc.
08.10.2011
41
Aspect-Oriented SW Development
Nearly all SW has localized features, functions and information content. User or customer concerns or needs must be included. These can be high-level concerns like security or lower-level such as marketing business rules or systemic such as memory management.
08.10.2011
42
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.
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
44

Software Engineering: Dr. S. N Ahsan

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Engineering: Dr. S. N Ahsan

Transféré par

Droits d'auteur :

Formats disponibles

Software Engineering

Software Construction Software Management

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Software Common Process Framework

A Generic Process Framework

Communication Planning Modeling Construction Deployment

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Software Process Models

Prescriptive Process Models

Incremental Process Models Evolutionary Process Models

Specialized Process Models

The Unified Process

Prescriptive Process Models

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

When to use the Waterfall Model

Dr. S. N Ahsan, IQRA-University

V-Shaped SDLC Model

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

When to use the V-Shaped Model

Dr. S. N Ahsan, IQRA-University

Incremental Development Model

Dr. S. N Ahsan, IQRA-University

Incremental Model Strengths

Dr. S. N Ahsan, IQRA-University

Incremental Model Weaknesses

Dr. S. N Ahsan, IQRA-University

When to use the Incremental Model

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

When to use RAD

Dr. S. N Ahsan, IQRA-University

Evolutionary Process Models

Dr. S. N Ahsan, IQRA-University

Prototyping (Evolutionary Model)

Dr. S. N Ahsan, IQRA-University

Prototyping (Evolutionary Model)

Design Design Implementation Implementation Testing Testing Maintenance

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

Dr. S. N Ahsan, IQRA-University

When to use Prototyping

Dr. S. N Ahsan, IQRA-University

The Spiral Model

Dr. S. N Ahsan, IQRA-University

Spiral Model (Evolutionary Model)

Dr. S. N Ahsan, IQRA-University

Spiral Model (Evolutionary Model)

REVIEW Requirements plan Life-cycle plan

Risk anal y sis Prototype 1 Concept of Operation

Simulations, models, benchmarks S/W requirements Product design

Development plan Integration and test plan

Plan next phase

Spiral Model Strengths

Spiral Model Weaknesses

When to use Spiral Model