SEQA Unit1

Software Engineering & Quality Assurance
Unit 1 Software Product & Process
Balasubba Raman Guruswamy
Balasubba Raman Guruswamy

SEQA - Unit 1 - Software Product & Process
Professor in IT Dept ME in Electrical Engineering, Power Systems, NIT Trichy (1979) Diploma in Programming in IISc (1975-77) Post Graduate Diploma in Software Engg , NCST (1994-96) 22 years experience in Information Technology Industry Mazagon Docks, Sigma Consultants, ABB, Mphasis, PSI Data Systems, Karnataka Govt, Virginia Panel Corp., Merit Systems, Kathir College of Engineering
16-Dec-12
Introduction
Software Engineering A Practitioners Approach, Roger S Pressman Software Engineering, Bali-Bali Software Engineering & Quality Assurance, A A Puntambekar
16-Dec-12
Reference Books
What is software? What is software Engineering? Software Process Software Process Model Costs / efforts in software engineering Good Software Challenges in software engineering Software characteristics Goals/objectives of software engineering Software Myths Software crisis Software Product vs program
16-Dec-12
4
Introduction
A logical rather than physical system element

software is engineered software doesnt wear out software is custom built software is complex
1) instructions (programs) that when executed provide desired function and performance 2) data structures that enable the programs to adequately manipulate information 3) documents that describe the operation and use of the programs
16-Dec-12
What is software? software?
Software is a product
Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information
Software is a vehicle for delivering a product

Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software tools)
SEQ AUnit 1Soft 6 ware Prod uct & Proc ess
16-Dec-12
Softwares Dual Role
Defined by IEEE 610.12610.12-1990 as: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches in (1).
16-Dec-12
What is software Engineering? Engineering?
Infant mortality
Wear out
Time
16-Dec-12
Failure (Bathtub) Curve for Hardware
Failure Rate
increased failure rate due to side effects
Failure rate
change actual curve
idealized curve Time
16-Dec-12
Wear vs. Deterioration (for software)
system software real real-time software business software engineering/scientific software embedded software PC software WebApps (Web applications) AI software Mobile Apps
10
16-Dec-12
Software Applications
Data mining Grid computing Cognitive machines Software for nanotechnologies
Ubiquitous computingwireless networks Netsourcingthe Web as a computing engine Open sourcefree source code open to the computing community Also
16-Dec-12
Software Software New Categories
11
12
Software is engineered, not manufactured Software does not wear out Frequent changes in software -> may deteriorate No spare parts for software Most software is custom built rather then being assembled from components
16-Dec-12
Software characteristics
13
Satisfy user requirements High reliability Human lives, money, customer relationship Low maintenance costs software design -> high quality Delivery on time Low production costs High performance - optimum speed and memory usage Ease of Use/reuse components
16-Dec-12
Goals/objectives of software engineering
Why must it change?

software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment.
16-Dec-12
Legacy Software
14
Both are key aspects in software engineering We move from an emphasis on product to process, and back and forth

Structured programming - Product Structured analysis and design - Process Data encapsulation (OO languages) - Product Capability Maturity Model/ISO9000 - Process Next step?
We need to be able to deliver quality software products to our customers with a consistent, well-managed and cost-effective process Product and process are not a dichotomy
15
16-Dec-12
Product and Process
Is not the same as a hardware product

A software product should

perform the required function be reliable be maintainable be efficient have an appropriate user interface have an appropriate lifetime
16
Software is developed or engineered, it isnt manufactured like a personal computer Software doesnt wear out Most software is custom-built, rather than being assembled from existing components
16-Dec-12
The Software Product
Is composed of

requirements, analysis & design documents, walk-through minutes, test plan, user manuals, etc.
Two main types of product

Generic - eg. Windows, Macintosh application software Custom - Systems created for specific application areas
17
Programs Data Documentation
16-Dec-12
The Software Product
The Software Process is a description of the process which guides software engineers as they work by identifying their roles and tasks.
18
The set of activities and associated results which produce a software product The sequence of steps required to develop and maintain software Sets out the technical and management framework for applying methods, tools and people to the software task Definition:
16-Dec-12
Software Process
19
Understandability Visibility Supportability Acceptability Reliability Robustness Maintainability Rapidity
16-Dec-12
Characteristics of a good process
Software Engineering
tools methods process model a quality focus
SEQ AUnit 1Soft ware Prod uct & Proc ess
20
16-Dec-12
A Layered Technology
tasks milestones,deliverables SQA checkpoints Umbrella Activities
21
Common process framework Framework activities Task Sets
16-Dec-12
A Common Process Framework
Analysis of requirements Design
Construction
Code generation Testing
Deployment
22
Communication Planning Modeling
16-Dec-12
Framework Activities
23
Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management
16-Dec-12
Umbrella Activities
60-100x
1.5-6x 1x Development After release
Definition
24
16-Dec-12
The Cost of Change
How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control? How do we upgrade an aging "software plant?" How do we avoid disastrous time delays? How do we successfully institute new software technologies?
25
16-Dec-12
Challenges in software engineering
Management
We have standards Well add more people to catch up I outsourced it, Im done
Customer
We have general objectives, lets start Change is easily accommodated
Practitioner / Software Developer

Well write it and be done I cant assess quality until it is running I only need deliver code Sooner you begin writing code, longer Software engineering is about it takes to complete the project meaningless documents Quality from inception of a project
Disaster Unambiguous requirements are developed thru effective and continuous communication betn Customer and Developer Change can result in major design change
Working program is part of delivery SE is about developing quality product -> reduced work -> faster delivery times
26
Are the standards used? Is it complete / adaptable? Will it improve timetime-to to-delivery? Educating new comers Expertise needed to manage outsourced projects
16-Dec-12
Software Myths
5Jan12
Affect managers, customers (and other nontechnical stakeholders) and practitioners Are believable because they often have elements of truth, but Invariably lead to bad decisions, therefore Insist on reality as you navigate your way through software engineering
SEQ AUnit 1Soft ware Prod uct & Proc ess
27
16-Dec-12
Software Myths
28
Satisfy User requirements High reliability Low Maintenance Costs Delivery on time Low production costs High performance Ease of reuse
16-Dec-12
Goals / objectives of software engineering
29
Poor quality software Exceed budget Late delivery < 100% of user reqts Unreliable software Difficult to maintain
Reasons
Lack of communication Increase in size/scope Increase in cost Project mgt problem Lack of understanding Lack of automation Highly optimistic estimation
16-Dec-12
Software crisis
Any one directly interested in success of the project

Users / customers Managers Software developers Project finance providers
30
16-Dec-12
Stake holder
CMMI SPICE ISO 9001:2000
31
The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment options are available:
16-Dec-12
Process Assessment
The CMMI defines each process area in terms of specific goals and the specific practices required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective Specific practices achieve a goal using a set of process-related activities
Level 1 : Initial - Few processes are defined and individual efforts Level 2 : Repeatable Basic project management processes are established and repeatable Level 3 : Defined Processes are standardised, documented and followed Level 4 : Managed Metrics for Software processes and products are controlled using detailed measures Level 5 : Optimised Established mechanisms for planning and implementing change. Innovative ideas and technologies are used.
SEQ AUnit 1Soft 32 ware Prod uct & Proc ess
16-Dec-12
The CMMI
33
Capability Maturity Model is used in assessing how well an organisation processes allow to complete and manage new software projects
16-Dec-12
Software Process
identifies modifications to
is examined by
identifies capabilities and risk of
Software Process Assessment
Software Process Improvement
leads to
leads to
Capability Determination
motivates
34
16-Dec-12
Assessment and Improvement
Recommends five framework activities:

Planning High-level design High-level design review Development Postmortem
stresses the need for each software engineer to identify errors early and as important, to understand the types of errors
35
16-Dec-12
Personal Software Process (PSP)
36
Each project is launched using a script that defines the tasks to be accomplished Teams are self-directed Measurement is encouraged Measures are analyzed with the intent of improving the team process
16-Dec-12
Team Software Process (TSP)
Primary Goal of Any Software Process: High Quality

Remember: High quality = project timeliness Why? Less rework!
37
16-Dec-12
Verification
Set of activities carried out to confirm that software correctly implements the specific functionality
Validation
Set of activities to ensure that the software has been built to satisfy the customer requirements
38
16-Dec-12
Verification & Validation
39
Unit testing Module testing Sub-system testing System testing Acceptance testing
16-Dec-12
Testing Steps
General skills
Interviewing skills, Team work skills, Facilitation skills, Negotiation skills, Analytical skills Problem solving, Presentation skills, Modelling
Programming skills
Data structures & algorithms, Programming skills, ToolsCompilers, Debuggers, editors
Communication skills
Spoken, written, presentations, Teamwork, Customer interaction
Design skills
Familiarity with multiple approaches, Different application domains, Application domain, Models, Coding
40
16-Dec-12
Software Engineer
Define software Engineering. What is software? List elements in Computer-Based system. Who is a stakeholder? What are the characteristics of software? What are the various categories of software? What are the key challenges in software development? Define software process. What are the basic activities of a software process?
41
What is validation? What is verification? What are the steps followed in testing?
16-Dec-12
SEQASEQA - SAQ Unit 1A (2 Marks)
42
Describe the umbrella activities of a software process? (4) What are the software myths from various stakeholders points of view and how they affect the software process? (8) Compare Hardware and software failure rates using graphs(8) What is software crisis? (4) Describe the goals and objectives of software engineering. (6) What are PSP and TSP? (6) Describe the skills expected from a software engineer. (8)
16-Dec-12
SEQASEQA - LAQ Unit 1A
Waterfall model Prototype Model Spiral Model Rapid Application Development (RAD)
43
Software paradigm or Software Development Life Cycle (SDLC) Diagrammatic representation of activities required to develp a software product SDLC consists of phases, activities, Order of execution Models:
16-Dec-12
SDLC Model
44
Waterfall Model
16-Dec-12
Requirements defines needed information, function, behavior, performance and interfaces. Design data structures, software architecture, interface representations, algorithmic details. Implementation source code, database, user documentation, testing.
45
16-Dec-12
Waterfall Model
46
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
16-Dec-12
Waterfall Strengths
All requirements must be known upfront Deliverables created for each phase are considered frozen inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
47
16-Dec-12
Waterfall Deficiencies
48
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.
16-Dec-12
When to use the Waterfall Model
Waterfall Model
Linear-sequential model or Classic life cycle model Requirements gathering and analysis Planning Project plan, Resource requirements Modeling detailed analysis and design (Data structure, Software
architecture, Interfaces, Algorithms, Pseudo code)
16-Dec-12
Construction Coding and Testing Programs are tested for

errors and functional behaviour, performance
Deployment Installation in customer site and maintenance

(correct run time errors, enhance system functionality) Benefits : Simple to implement Useful for quick development of small systems Drawbacks: Difficult for customers to state all requirements explicitly Intermediate change requirements cause confusion Working model can be seen only at the end
49
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
50
16-Dec-12
V-Shaped SDLC Model
Project and Requirements Planning allocate resources Product Requirements and Specification Analysis complete specification of the software system Architecture or High-Level Design defines how software functions fulfill the design Detailed Design develop algorithms for each architectural component
Integration and Testing check that modules interconnect correctly Unit testing check that each module acts as expected Coding transform algorithms into software
51
Production, operation and maintenance provide for enhancement and corrections System and acceptance testing check the entire software system in its environment
16-Dec-12
V-Shaped Steps
52
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
16-Dec-12
V-Shaped Strengths
53
Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities
16-Dec-12
V-Shaped Weaknesses
54
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
16-Dec-12
When to use the VV-Shaped Model
55
Incremental Model
16-Dec-12
56
Construct a partial implementation of a total system Then slowly add increased functionality The incremental model prioritizes requirements of the system and then implements them in groups. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.
16-Dec-12
Incremental SDLC Model
57
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
16-Dec-12
Incremental Model Strengths
58
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
16-Dec-12
Incremental Model Weaknesses
59
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
16-Dec-12
When to use the Incremental Model
60
Rapid Application Development (RAD) Model

16-Dec-12
The RAD Model

M o d e lin g
business m odeling dat a m odeling process m odeling
Co n st ru ct io n
Communicat ion
Team # 2
Mo d eling
busi ness m odeli ng dat a m od eli ng process m odeli ng
Planning Team # 1 Mode ling

business modeling dat a modeling process modeling Co nst ruct io n
com ponent reuse aut om at ic code generat ion t est ing
De ployme nt
int egrat ion deliv ery feedback
Const ruct ion

component reuse aut omat ic code generat ion t est ing
61
6 0 - 9 0 days
com ponent reuse aut om at ic code generat ion t est ing
16-Dec-12
Team # n
62
Requirements planning phase (a workshop utilizing structured discussion of business problems) User description phase automated tools capture information from users Construction phase productivity tools, such as code generators, screen generators, etc. inside a time-box. (Do until done) Cutover phase -- installation of the system, user acceptance testing and user training
16-Dec-12
Rapid Application Model (RAD)
63
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.
16-Dec-12
RAD Strengths
64
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.
16-Dec-12
RAD Weaknesses
65
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
16-Dec-12
When to use RAD
66
Prototyping
16-Dec-12
Quick plan Quick
Communicat ion
plan SEQA - Unit 1 - Software Product & Process
communication
Mode ling Modeling Quick de sign
Quick design
Deployment Deployment Delivery delivery & & Feedback
feedback
Construction of of prototype prot ot ype
Const ruct ion
67
16-Dec-12
Evolutionary Models: Prototyping
68
Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
16-Dec-12
Prototyping Model
the database user interface algorithmic functions
Demonstrate the prototype, the user evaluates for problems and suggests improvements. This loop continues until the user is satisfied
69
A preliminary project plan is developed An partial high-level paper model is created The model is source for a partial requirements specification A prototype is built with basic and critical attributes The software team builds
16-Dec-12
Prototyping Steps
Throwaway prototyping
1. 2. 3. 4. 5. 6. Write preliminary requirements Design the prototype User experiences/uses the prototype, specifies new requirements Repeat if necessary Write the final requirements Develop the real products
Evolutionary prototyping
System is continually refined and rebuilt
70
16-Dec-12
Prototype types
71
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
16-Dec-12
Prototyping Strengths
72
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)
16-Dec-12
Prototyping Weaknesses
73
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.
16-Dec-12
When to use Prototyping
74
Spiral Model
16-Dec-12
75
Adds risk analysis, and 4gl RAD prototyping to the waterfall model Each cycle involves the same sequence of steps as the waterfall process model
16-Dec-12
Spiral SDLC Model
76
Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, interface, etc.
16-Dec-12
Spiral Quadrant - Determine objectives, alternatives and constraints
77
Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development
16-Dec-12
Spiral Quadrant - Evaluate alternatives, identify and resolve risks
78
Typical activites: Create a design Review design Develop code Inspect code Test product
16-Dec-12
Spiral Quadrant - Develop nextnext-level product
79
Typical activities Develop project plan Develop configuration management plan Develop a test plan Develop an installation plan
16-Dec-12
Spiral Quadrant - Plan next phase
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
80
16-Dec-12
Spiral Model Strengths
Time spent for evaluating risks too large for small or lowrisk 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 non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
81
16-Dec-12
Spiral Model Weaknesses
82
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)
16-Dec-12
When to use Spiral Model
Negotiations begins in a each pass of the spiral
83
Good communication between Software development team and customer Customers WIN Satisfies most of the needs Developers WIN Work done with realistic and achievable budgets and deadlines
16-Dec-12
WinWin -Win Spiral Model
84
Unified Processa use-case driven, architecture-centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)
16-Dec-12
Rational Unified Process (RUP)
UP Phases
UP Phases
Inception Elaboration Construction Transition Production
Workflows
Requirements Analysis Design
Implementation Test Support Iterations #1 #2 #n-1 #n
85
16-Dec-12
86
Speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods
16-Dec-12
Agile SDLCs
87
Adaptive Software Development (ASD) Feature Driven Development (FDD) Dynamic Software Development Method (DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)
16-Dec-12
Some Agile Methods
Elements of a computer-based system

Software Hardware People Database Documentation Procedures
Systems A hierarchy of macro-elements
System Engineering To manage all above elements
88
16-Dec-12
ComputerComputer -based system
Software engineering occurs as a consequence of system engineering System engineering may take on two different forms depending on the application domain Business process engineering conducted when the context of the work focuses on a business enterprise Product engineering conducted when the context of the work focuses on a product that is to be built Both forms bring order to the development of computer-based systems work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system
16-Dec-12 89
System Engineering
World View
Domain View
Element View
Component View
16-Dec-12 90
System Engineering Hierarchy
At the world view level, a very broad context is established At the bottom level, detailed technical activities are conducted by the relevant engineering discipline (e.g., software engineering)
"Always design a thing by considering it in its next larger context a chair in a room, a room in a house, a house in an environment, and environment in a city plan"
The system engineering process begins with a world view; the business or product domain is examined to ensure that the proper business or technology context can be established The world view is refined to focus on a specific domain of interest Within a specific domain, the need for targeted system elements is analyzed Finally, the analysis, design, and construction of a targeted system element are initiated
16-Dec-12 91
System Engineering Process
92
Business Process Engineering

16-Dec-12
Three different architectures are analyzed and designed within the context of business objectives and goals:
data architecture applications architecture technology infrastructure
data architecture provides a framework for the information needs of a business or business function application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose technology infrastructure provides the foundation for the data and application architectures
Business process engineering defines architectures that will enable a business to use information effectively Involves the specification of the appropriate computing architecture and the development of the software architecture for the organization's computing resources It includes the hardware and software that are used to support the applications and data
16-Dec-12 93
Business Process Engineering
Information strategy planning (ISP)

strategic goals defined success factors/business rules identified enterprise model created
Business area analysis (BAA)

processes/services modeled interrelationships of processes and data
Application Engineering
a.k.a ... software engineering modeling applications/procedures that address (BAA) and constraints of ISP
Construction and delivery

using CASE and 4GTs, testing
94
16-Dec-12
BPE Hierarchy
define systems that are problematic defining systems that are incompatible with new information model begin to establish re-engineering priorities
95
define naturally cohesive groupings of business functions and data (Martin) perform many of the same activities as ISP, but narrow scope to individual business area identify existing (old) information systems / determine compatibility with new ISP model
16-Dec-12
Business Area Analysis
Product Engineering
Product Requirements Engineering

Human Engineering Hardware Engineering Software Engineering Database Engineering
Function
Data and Classes
Behavior
Analysis Modeling Design Modeling
Data/Class Design
Architectural Interface Design Design
Component Design
Construction
System Component Engineering
16-Dec-12 97
Product Engineering Hierarchy
Product engineering translates the customer's desire for a set of defined capabilities into a working product It achieves this goal by establishing a product architecture and a support infrastructure
Product architecture components consist of people, hardware, software, and data Support infrastructure includes the technology required to tie the components together and the information to support the components
Requirements engineering elicits the requirements from the customer and allocates function and behavior to each of the four components System component engineering happens next as a set of concurrent activities that address each of the components separately
Each component takes a domain-specific view but maintains communication with the other domains The actual activities of the engineering discipline takes on an element view
Analysis modeling allocates requirements into function, data, and behavior Design modeling maps the analysis model into data/class, architectural, interface, and component design
16-Dec-12 98
Product Engineering
99
What is the major difference between system engineering and software engineering? How does project risk factor affect the spiral model of software development? Give two project areas that are not amenable to prototyping. What is win-win spiral model? Which model is used when staffing is unavailable and why? What are the disadvantages of evolutionary model? How to select the appropriate prototyping approach? State the importance of use cases. Compare product engineering and process engineering.
16-Dec-12
SEQASEQA -SAQ SAQ-Unit 1B (2 Marks)
Describe SDLC with an example. (4) Give a brief comparison of various life cycle models. (8) Explain different phases of waterfall model and compare it with prototype and spiral models. (8) Describe incremental model (4) Give a brief note on RAD Model (4) Explain in detail different types of prototyping with suitable examples. (8) What are the advantages and disadvantages of prototyping? (4) Describe spiral model and give its advantages, disadvantages (8) Briefly explain the activities of business process engineering. (8) Explain difference between products, projects and processes (4) Give an overview of product engineering. (8) Depict using diagrams , System Engineering hierarchy and Product engineering hierarchy. (8)
100
16-Dec-12
SEQASEQA -LAQ LAQ-Unit 1B

SEQA Unit1

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SEQA Unit1

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Engineering & Quality Assurance

Unit 1 Software Product & Process

Balasubba Raman Guruswamy

Balasubba Raman Guruswamy

SEQA - Unit 1 - Software Product & Process

A logical rather than physical system element

SEQA - Unit 1 - Software Product & Process

What is software? software?

Software is a vehicle for delivering a product

SEQ AUnit 1Soft 6 ware Prod uct & Proc ess

Softwares Dual Role

SEQA - Unit 1 - Software Product & Process

What is software Engineering? Engineering?

SEQA - Unit 1 - Software Product & Process

Failure (Bathtub) Curve for Hardware

increased failure rate due to side effects

change actual curve

idealized curve Time

Wear vs. Deterioration (for software)

SEQA - Unit 1 - Software Product & Process

Data mining Grid computing Cognitive machines Software for nanotechnologies

SEQA - Unit 1 - Software Product & Process

Software Software New Categories

SEQA - Unit 1 - Software Product & Process

SEQA - Unit 1 - Software Product & Process

Goals/objectives of software engineering

Why must it change?

SEQA - Unit 1 - Software Product & Process

Product and Process

Is not the same as a hardware product

A software product should

SEQA - Unit 1 - Software Product & Process

The Software Product

Two main types of product

SEQA - Unit 1 - Software Product & Process

Programs Data Documentation

The Software Product

SEQA - Unit 1 - Software Product & Process

SEQA - Unit 1 - Software Product & Process

Understandability Visibility Supportability Acceptability Reliability Robustness Maintainability Rapidity

Characteristics of a good process

tasks milestones,deliverables SQA checkpoints Umbrella Activities

SEQA - Unit 1 - Software Product & Process

Common process framework Framework activities Task Sets

A Common Process Framework

Analysis of requirements Design

SEQA - Unit 1 - Software Product & Process

Communication Planning Modeling

SEQA - Unit 1 - Software Product & Process

1.5-6x 1x Development After release

The Cost of Change

SEQA - Unit 1 - Software Product & Process

Challenges in software engineering

Practitioner / Software Developer

SEQA - Unit 1 - Software Product & Process

SEQ AUnit 1Soft ware Prod uct & Proc ess

SEQA - Unit 1 - Software Product & Process

Goals / objectives of software engineering

SEQA - Unit 1 - Software Product & Process

Any one directly interested in success of the project

SEQA - Unit 1 - Software Product & Process

CMMI SPICE ISO 9001:2000

SEQA - Unit 1 - Software Product & Process