0% found this document useful (0 votes)
32 views18 pages

(MMU) Software Varification and Validation - Lecture 2

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views18 pages

(MMU) Software Varification and Validation - Lecture 2

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

LECTURE 2

Major Components in a Software Product

Customer Requirements & Product Specifications


HIGHLIGHTS
Software Design Document & Test Documents

Software Development Life Cycle Models


 Commercial software development involves dozens, hundreds
and even thousands of team members to work in various
different roles under a tight schedule.
SOFTWARE  A student or hobbyist only develop a small program. The
PRODUCT process to develop the commercial software and the small
project are different. One is working as a team and another
one is working individually.
Product Specification
Product Reviews
Design Documents
Schedules
SOFTWARE Feedback from Previous Version
Competitive Information
ABSTRACTS
Test Plans
Customers Surveys
Usability Data
Look and Feel Specifications
Software Architecture and Software Code.
The software product development team must find out what the customer wants.

Some teams simply guess the customers’ requirement.

Most of the teams collect software, competitive product information, magazine reviews, focus groups, and
numerous other methods, some formal, some not.
All these information are studied, condensed, and interpreted to decide exactly what features the
software product should have.

CUSTOMER A focus group is used to gather the direct feedback from the potential customers of a software product.

REQUIREMENTS The focus groups are often organized by independent survey companies who set up offices in shopping
malls.
The surveyors typically walk around the mall with a clipboard and ask passers-by if they want to take
part in a study.
Once you fit their demographic, they’ll invite you to return for a few hours to participate with several
other people in focus group.
They will ask more detailed questions about computer software. You may be shown various software
boxes and be asked to choose your favorite. All information gathered are kept confidentially.
You get paid for your time.
You are given a task to develop a coffee machine in FCI
MMU. This is expected to be part MMU Smart University
initiative. You are required to obtain the user requirement
EXERCISE from MMU students.

You are given 20 mins. To obtain the user requirements.


SPECIFICATIONS

 The result of the requirement studies is really raw data.


 It doesn’t describe the proposed product, it confirms whether it should (or shouldn’t) be created and what features
the customers want.
 The specifications take all this information plus any unstated but mandatory requirements and truly define what the
product will be, what it will do, and how it will look.
Architecture
A document that describes the overall design of the software, including description of all the major
pieces and how they interact with each other.

Data Flow Diagram


A formalized diagram that shows how data moves through a program. It’s sometimes referred to
as a bubble chart because it’s drawn by using circles and lines.
SOFTWARE
DESIGN State Transition
Diagram Another formalized diagram that breaks the software into basic states, or conditions, and
shows the means for moving from one state to the next.
DOCUMENTS
Flowchart
The traditional means for pictorially describing a program’s logic Flowcharting isn’t very popular
today, but, when it’s used, writing the program code from a detailed flowchart is a very simple
process.

Commented Code
There’s an old saying that you may write code once, but, it will be read by someone at least 10
times. Properly embedding useful comments in the software code itself is extremely important, so
that programmers assigned to maintain the code can more easily figure out what it does and how.
 Test Plan describes the overall method to be used to verify
that the software meets the product specification and the
customer’s needs. It includes the quality objectives, resource
needs, schedules, assignments, methods and so forth.
 Test Cases list the specific items that will be tested and
describe the detailed steps that will be followed to verify the
software.
 Bug Reports describe the problems found as the test cases are
TEST DOCUMENTS followed. These could be done on paper but are often
tracked in a database.
 Test Tools and Automation. If your team is using automated
methods to test your software, the tools you use, either
purchased or written in-house, must be documented.
 Metrics, statistics, and summaries convey the progress being
made as the test work progresses. They take the form of
graphs, charts and written reports.
SOFTWARE PRODUCT

Setup & Help Samples and Readme file


Files Examples

Label and Users Manuals Product Support


Stickers Information

Samples Error Messages


Project managers,
program managers or producers drive the project from beginning to end. They’re usually
responsible for writing the product spec, managing the schedule, and making the critical decisions
and trade-offs.

Architects or system engineers


Technical experts on the product team. They’re usually very experienced and therefore are
qualified to design the overall system architecture or design for software. They work very closely
with the programmers.

SOFTWARE Programmers, developers, or coders


Design and write software and fix the bugs that are found. They work closely with the architects
PROJECT STAFF and project managers to create the software. Then, they work closely with the project managers
and testers to get the bugs fixed.

Testers or QA (Quality Assurance)


Responsible for finding and reporting problems in the software product. They work closely with all
members of the team as they develop and run their tests, and report the problems they find.

Configuration Management or Builder


Handles the process of pulling together all the software written by the programmers and all the
documentation created by the writers and putting it together into a single package.
Big-Bang Model

SOFTWARE
Code-and-Fix Model
DEVELOPMENT
LIFE CYCLE
MODELS Waterfall Model

Spiral Model
BING BANG MODEL
CODE-AND-FIX
MODEL
WATERFALL
MODEL
SPIRAL MODEL
Software Design Description (SDD)
A representation of software created to facilitate analysis,planning, implementation, and
decision-making. The software design description is used as a medium for communicating
software design information and may be thought of as a blueprint or model of the system.
Test Case
A set of test inputs, execution conditions, and expected results developed for a particular
objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.
Testware
DEFINITIONS All products produced by the testing effort, e.g., documentation and data.

Document
A medium, and the information recorded on it, that generally has permanence and can be
read by a person or a machine. Examples in software engineering include project plans,
specifications, test plans, and user manuals.
Documentation
A collection of documents on a given subject. Any written or pictorial information describing,
defining, specifying, reporting, or certifying activities, requirements, procedures, or results.
END OF WEEK 2

You might also like