The Design Model: //connection To The Database

The design model
Inheritance in PHP
Unless autoloading is used, then classes must be defined before they are
used. If a class extends another, then the parent class must be declared
before the child class structure. This rule applies to classes that inherit
other classes and interfaces.
<?php class foo
{ public function printItem($string) {
echo 'Foo: ' . $string . PHP_EOL;
} public function printPHP()
{ echo 'PHP is great.' . PHP_EOL;
}}class bar extends foo
{ public function printItem($string)
{ echo 'Bar: ' . $string . PHP_EOL;
}}
$foo = new foo();
$bar = new bar();
$foo->printItem('baz'); // Output: 'Foo: baz'
$foo->printPHP(); // Output: 'PHP is great'
$bar->printItem('baz'); // Output: 'Bar: baz'
$bar->printPHP(); // Output: 'PHP is great'
?>
JavaScript is a scripting language most often used for client-side
web development
JavaScript was originally developed by Brendan Eich of Netscape
under the name Mocha, later LiveScript, and finally renamed to
JavaScript
JavaScript was first introduced and deployed in the Netscape
browser version 2.0B3 in December of 1995
JavaScript was designed to add interactivity to HTML pages
JavaScript is a scripting language
A JavaScript consists of lines of executable computer code
A JavaScript is usually embedded directly into HTML pages
JavaScript is an interpreted language (means that scripts
execute without preliminary compilation)
Everyone can use JavaScript without purchasing a license
What javascript do ?
JavaScript gives HTML designers a programming tool
JavaScript can put dynamic text into an HTML page
JavaScript can react to events
JavaScript can read and write HTML elements
JavaScript can be used to validate data
JavaScript can be used to detect the visitor's browser
JavaScript can be used to create cookies
JavaScript vs Java
JavaScript and Java has only syntactic relationship
Characterized by many as a marketing ploy by Netscape to give
JavaScript the cachet of what was then the hot new web-
programming language..
Despite the name, JavaScript is unrelated to the Java
programming language
Java (developed by Sun Microsystems) is a powerful and much
more complex programming language
Example
The HTML <script> tag is used to insert a JavaScript into an
HTML page.
<html> <body> <script type="text/javascript">
document.write("Hello World!")
</script> </body></html>
JavaScript Popup Boxes
1) Alert : An alert box is often used if you want to make sure information
comes through to the user.alert("sometext")
2)Confirm: A confirm box is often used if you want the user to verify or
accept something.When a confirm box pops up, the user will have to click
either "OK" or "Cancel" to proceed. If the user clicks "OK", the box returns
true. If the user clicks "Cancel", the box returns false.
confirm("sometext")
3) A prompt box is often used if you want the user to input a value
before entering a page.When a prompt box pops up, the user will have to
click either "OK" or "Cancel" to proceed after entering an input value. If
the user clicks "OK" the box returns the input value. If the user clicks
"Cancel" the box returns null.Syntax:prompt("sometext","defaultvalue")
Event handler
onAbort onBlur onChange onClick onDragDrop onError onFocus
onKeyDown onKeyPress onKeyUp onLoad onMouseDown
onMouseMoveonMouseOut onMouseOver onMouseUponMove onReset
onResize onSelect onSubmit onUnload

<?php
$username = "your_name";
$password = "your_password";
$hostname = "localhost";
//connection to the database
$dbhandle = mysql_connect($hostname, $username, $password)
or die("Unable to connect to MySQL");
echo "Connected to MySQL<br>";
?>
PHP is an acronym for "PHP Hypertext Preprocessor"
PHP is a widely-used, open source scripting language
PHP scripts are executed on the server
PHP costs nothing, it is free to download and use
PHP can generate dynamic page content
PHP can create, open, read, write, delete, and close files on the server
PHP can collect form data
PHP can send and receive cookies
PHP can add, delete, modify data in your database
PHP can restrict users to access some pages on your website
PHP can encrypt data

<?php
$con=mysqli_connect("example.com","peter","abc123","my_db");
// Check connection
if (mysqli_connect_errno()) {
echo "Failed to connect to MySQL: " . mysqli_connect_error();
}mysqli_close($con);?>
// Create table
$sql="CREATE TABLE Persons(FirstName CHAR(30),LastName CHAR(30),Age INT)";
// Execute query
if (mysqli_query($con,$sql)) {
echo "Table persons created successfully";
} else { echo "Error creating table: " .
mysqli_error($con);
} mysqli_close($con);?>
//Inserting Data Into Table
mysqli_query($con,"INSERT INTO Persons (FirstName, LastName, Age)
VALUES ('Peter', 'Griffin',35)"); mysqli_close($con);?>
//Retrieving Records
$result = mysqli_query($con,"SELECT * FROM Persons");
while($row = mysqli_fetch_array($result)) {
echo $row['FirstName'] . " " . $row['LastName'];
echo "<br>";} mysqli_close($con);?>
?>

In PHP, there are three types of arrays:
Indexed arrays - Arrays with numeric index
There are two ways to create indexed arrays:
The index can be assigned automatically (index always starts at 0):
$cars=array("Volvo","BMW","Toyota");
or the index can be assigned manually:
$cars[0]="Volvo";
$cars[1]="BMW";
$cars[2]="Toyota";
The following example creates an indexed array named $cars, assigns three elements to it, and then
prints a text containing the array values:
Example
<?php
$cars=array("Volvo","BMW","Toyota");
echo "I like " . $cars[0] . ", " . $cars[1] . " and " . $cars[2] . ".";
?>
Associative arrays - Arrays with named keys
Associative arrays are arrays that use named keys that you assign to them.
There are two ways to create an associative array:
$age=array("Peter"=>"35","Ben"=>"37","Joe"=>"43");
or:
$age['Peter']="35";
$age['Ben']="37";
$age['Joe']="43";
The named keys can then be used in a script:
Example
<?php
$age=array("Peter"=>"35","Ben"=>"37","Joe"=>"43");
echo "Peter is " . $age['Peter'] . " years old.";
?>

Multidimensional arrays - Arrays containing one or more arrays

System Engineering Hierarchy:- Regardless of its domain of focus, system
engineering encompasses a collection of top-down and bottom-up
methods to navigate the hierarchy.
System Modeling:- System engineering is a modeling process. Whether
the focus is on the world view or the detailed view. To construct a system
model, the engineer should consider a number of restraining factors:- 1.
Assumptions 2. Simplifications 3. Limitations 4. Constraints 5.
Preferences
System Simulation: - Adv 1. Study the behavior of a system without
building it. 2. Results are accurate in general, compared to analytical
model. 3. Help to find un-expected phenomenon, behavior of the
system. 4. Easy to perform ``What-If'' analysis.::::Disadv 1. Expensive to
build a simulation model. 2. Expensive to conduct simulation.
Sometimes it is difficult to interpret the simulation results

BUSINESS PROCESS ENGINEERING:- Business process modeling (BPM) in
systems engineering is the activity of representing processes of an
enterprise, so that the current process may be analyzed and improved.
BPM is typically performed by business analysts or managers seeking to
improve process efficiency, quality, and reduce waste. Any improvements
thus identified may or may not require information technology
involvement, although that is a common driver for modeling business
processes.

PRODUCT ENGINEERING: The goal of product engineering is to translate
the customers desire for a set of defined capabilities into a working
product. To achieve this goal, product engineeringlike business process
engineeringmust derive architecture and infrastructure. The
architecture encompasses four distinct system components: software,
hardware, data (and databases), and people.

REQUIREMENTS ENGINEERING:- Requirements engineering provides the
appropriate mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a reasonable solution,
specifying the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an operational
system The requirements engineering process can be described in five
distinct steps requirements elicitation requirements analysis and
negotiation requirements specification system modeling
requirements validation requirements management
SYSTEM MODELING: - Every computer-based system can be modeled as
an information transform using an input-processing-output template.
Using a representation of input, processing, output, user interface
processing, and self-test processing, a system engineer can create a
model of system components that sets a foundation for later steps in
each of the engineering disciplines. To develop the system model, a
system model template is used. The system engineer allocates system
elements to each of five processing regions within the template: (1) user
interface, (2) input, (3) system function and control, (4) output, and (5)
maintenance and self-test.
REQUIREMENTS ANALYSIS:- Requirements analysis is a software
engineering task that bridges the gap between system level requirements
engineering and software design. Requirements engineering activities
result in the specification of softwares operational characteristics
(function, data, and behavior), indicate software's interface with other
system elements, and establish constraints that software must meet.
Requirements analysis allows the software engineer (sometimes called
analyst in this role) to refine the software allocation and build models of
the data, functional, and behavioral domains that will be treated by
software. Requirements analysis provides the software designer with a
representation of information, function, and behavior that can
be translated to data, architectural, interface, and component-level
designs. Finally, the requirements specification provides the developer
and the customer with the means to assess quality once software is built.
Software requirements analysis may be divided into five areas of effort:
(1) problem recognition, (2) evaluation and synthesis, (3) modeling, (4)
specification, and (5) review. Initially
REQUIREMENTS ELICITATION FOR SOFTWARE:- Before requirements can
be analyzed, modeled, or specified they must be gathered through an
elicitation process. A customer has a problem that may be amenable to a
computer-based solution. A developer responds to the customer's
request for help.
1.Initiating the Process:- The most commonly used requirements
elicitation technique is to conduct a meeting or interview. The first
meeting between a software engineer (the analyst) and the customer can
be likened to the awkwardness of a first date between two adolescents.
2.Facilitated Application Specification Techniques:- Too often, customers
and software engineers have an unconscious "us and them" mind-set.
Rather than working as a team to identify and refine requirements, each
constituency defines its own "territory" and communicates through a
series of memos.
3.Quality Function Deployment:- Quality function deployment (QFD) is a
quality management technique that translates the needs of the customer
into technical requirements for software. QFD identifies three types of
requirements 1.Normal requirements. 2. Expected requirements.
3.Exciting requirements.
4. Use-Cases

ANALYSIS PRINCIPLES:- Over the past two decades, a large number of
analysis modeling methods have been developed. Investigators have
identified analysis problems and their causes and have developed a
variety of modeling notations and corresponding sets of heuristics to
overcome them. Each analysis method has a unique point of view.
However, all analysis methods are related by a set of operational
principles: 1. The information domain of a problem must be represented
and understood. 2. The functions that the software is to perform must be
defined. 3. The behavior of the software (as a consequence of external
events) must be represented. 4. The models that depict information,
function, and behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion. 5. The analysis process should
move from essential information toward implementation detail.
1.The Information Domain 2. Modeling 3. Partitioning 4. Essential and
Implementation Views
Software prototyping, refers to the activity of creating prototypes of
software applications, i.e., incomplete versions of the software program
being developed. It is an activity that can occur in software development
and is comparable to prototyping as known from other fields, such as
mechanical engineering or manufacturing. A prototype typically simulates
only a few aspects of, and may be completely different from, the final
product. Prototyping has several benefits: The software designer and
implementer can get valuable feedback from the users early in the
project. The client and the contractor can compare if the software made
matches the software specification, according to which the software
program is built. It also allows the software engineer some insight into
the accuracy of initial project estimates and whether the deadlines and
milestones proposed can be successfully met. Specification Principles:- Specification, regardless of the mode through
which we accomplish it, may be viewed as a representation process.
Requirements are represented in a manner that ultimately leads to
successful software implementation. 1. Separate functionality from
implementation. 2. Develop a model of the desired behavior of a system
that encompasses data and the functional responses of a system to
various stimuli from the environment. 3. Establish the context in which
software operates by specifying the manner in which other system
components interact with software. 4. Define the environment in which
the system operates and indicate how a highly intertwined collection of
agents react to stimuli in the environment (changes to objects) produced
by those agents. 5. Create a cognitive model rather than a design or
implementation model. The cognitive model describes a system as
perceived by its user community. 6. Recognize that the specifications
must be tolerant of incompleteness and augmentable.
THE ELEMENTS OF THE ANALYSIS MODEL:- The analysis model must
achieve three primary objectives: (1) to describe what the customer
requires, (2) to establish a basis for the creation of a software design, and
(3) to define a set of requirements that can be validated once the
software is built. To accomplish these objectives, the analysis model
derived during structured analysis.
At the core of the model lies the data dictionarya repository that
contains descriptions of all data objects consumed or produced by the
software. Three different diagrams surround the the core. The entity
relation diagram (ERD) depicts relationships between data objects. The
ERD is the notation that is used to conduct the data modeling activity.
The attributes of each data object noted in the ERD can be described
using a data object description. The data flow diagram (DFD) serves two
purposes: (1) to provide an indication of how data are transformed as
they move through the system and (2) to depict the functions (and
subfunctions) that transform the data flow. A description of each
function presented in the DFD is contained in a process specification
(PSPEC). The state transition diagram (STD) indicates how the system
behaves as a consequence of external events. To accomplish this, the STD
represents the various modes of behavior (called states) of the system
and the manner in which transitions are made from state to state.
DATA MODELING:- Data modeling answers a set of specific questions
that are relevant to any data processing application. 1. Data Objects,
Attributes, and Relationships. 2.Cardinality. The data model must be
capable of representing the number of occurrences objects in a given
relationship. Modality. The modality of a relationship is 0 if there is no
explicit need for the relationship to occur or the relationship is optional.
3. Entity/Relationship Diagrams:-

FUNCTIONAL MODELING AND INFORMATION FLOW:- Information is
transformed as it flows through a computer-based system. The system
accepts input in a variety of forms; applies hardware, software, and
human elements to transform it; and produces output in a variety of
forms. 1. Data Flow Diagrams:- As information moves through software,
it is modified by a series of transformations. A data flow diagram is a
graphical representation that depicts information flow and the
transforms that are applied as data move from input to output.
2. Extensions for Real-Time Systems:- Many software applications are
time dependent and process as much or more control- oriented
information as data. A real-time system must interact with the real world
in a time frame dictated by the real world.
3. Ward and Mellor Extensions:- Ward and Mellor extend basic structured
analysis notation to accommodate the following demands imposed by a
real-time system: Information flow is gathered or produced on a time-
continuous basis. Control information is passed throughout the system
and associated control processing.
FUNCTIONAL MODELING AND INFORMATION FLOW:- Information is
transformed as it flows through a computer-based system. The system
accepts input in a variety of forms; applies hardware, software, and
human elements to transform it; and produces output in a variety of
forms. 1. Data Flow Diagrams:- As information moves through software,
it is modified by a series of transformations. A data flow diagram is a
graphical representation that depicts information flow and the
transforms that are applied as data move from input to output.
2. Extensions for Real-Time Systems:- Many software applications are
time dependent and process as much or more control- oriented
information as data. A real-time system must interact with the real world
in a time frame dictated by the real world.
3. Ward and Mellor Extensions:- Ward and Mellor extend basic structured
analysis notation to accommodate the following demands imposed by a
real-time system: Information flow is gathered or produced on a time-
continuous basis. Control information is passed throughout the system
and associated control processing.
Behavioral modeling is an operational principle for all requirements
analysis methods. Yet, only extended versions of structured analysis
provide a notation for this type of modeling. The state transition diagram
represents the behavior of a system by depicting its states and the events
that cause the system to change state. In addition, the STD indicates what
actions (e.g., process activation) are taken as a consequence of a
particular event.
A state is any observable mode of behavior. For example, states for a
monitoring and control system for pressure vessels might be monitoring
state, alarm state, pressure release state, and so on. Each of these states
represents a mode of behavior of the system. A state transition diagram
indicates how the system moves from state to state.

The data dictionary is an organized listing of all data elements that are
pertinent to the system, with precise, rigorous definitions so that both
user and system analyst will have a common understanding of inputs,
outputs, components of stores and [even] intermediate calculations. The
data dictionary has been proposed as a quasi-formal grammar for
describing the content of objects defined during structured analysis.
SOFTWARE SCOPE:- The first activity in software project planning is the
determination of software scope. Function and performance allocated to
software during system engineering should be assessed to establish a
project scope that is unambiguous and understandable at the
management and technical levels. A statement of software scope must be
bounded Software scope describes the data and control to be processed,
function, performance, constraints, interfaces, and reliability. Functions
described in the statement of scope are evaluated and in some cases
refined to provide more detail prior to the beginning of estimation.
Because both cost and schedule estimates are functionally oriented,
some degree of decomposition is often useful.
SOFTWARE PROJECT ESTIMATION:- Software cost and effort estimation
will never be an exact science. Too many variables human, technical,
environmental, politicalcan affect the ultimate cost of software and
effort applied to develop it. However, software project estimation can be
transformed from a black art to a series of systematic steps that provide
estimates with acceptable risk. To achieve reliable cost and effort
estimates, a number of options arise: 1. Delay estimation until late in the
project. 2. Base estimates on similar projects that have already been
completed. 3. Use relatively simple decomposition techniques to
generate project cost and effort estimates. 4. Use one or more empirical
models for software cost and effort estimation.

RESOURCES:- The second software planning task is estimation of the
resources required to accomplish the software development effort.
1. Human Resources:- The planner begins by evaluating scope and
selecting the skills required to complete development. Both
organizational position and specialty are specified. For relatively
small projects (one person-year or less), a single individual may
perform all software engineering tasks, consulting with
specialists as required.
2. Reusable Software Resources:-
3. Environmental Resources
DECOMPOSITION TECHNIQUES:- Software project estimation is a form of
problem solving, and in most cases, the problem to be solved (i.e.,
developing a cost and effort estimate for a software project) is too
complex to be considered in one piece. For this reason, we decompose
the problem, re-characterizing it as a set of smaller (and hopefully, more
manageable) problems. Before an estimate can be made, the project
planner must understand the scope of the software to be built and
generate an estimate of its "size." 1. Software Sizing 2.Problem-Based
Estimation 3. LOC-Based Estimation 4. FP-Based Estimation 5.Process-
Based Estimation
LOC and FP estimation are distinct estimation techniques. Yet both have a
number of characteristics in common. The project planner begins with a
bounded statement of software scope and from this statement attempts
to decompose software into problem functions that can each be
estimated individually. LOC or FP (the estimation variable) is then
estimated for each function. Alternatively, the planner may choose
another component for sizing such as classes or objects, changes, or
business processes affected.
PROJECT PLANNING OBJECTIVES:- The objective of software project
planning is to provide a framework that enables the manager to make
reasonable estimates of resources, cost, and schedule. These estimates
are made within a limited time frame at the beginning of a software
project and should be updated regularly as the project progresses. In
addition, estimates should attempt to define best case and worst case
scenarios so that project outcomes can be bounded. The planning
objective is achieved through a process of information discovery that
leads to reasonable estimates. In the following sections, each of the
activities associated with software project planning is discussed.

Software engineering is a layered technology. Any engineering approach
(including software engineering) must rest on an organizational
commitment to quality.
Any engineering approach must rest on organizational commitment to
quality which fosters a continuous process improvement culture
The foundation for software engineering is the process layer.
Software engineering methods provide the technical how-to's for building
software.
Software engineering tools provide automated or semi-automated
support for the process and the methods.

Five Activities of a Generic Process framework:-
Communication: communicate with customer to understand
objectives and gather requirements
Planning: creates a map defines the work by describing the
tasks, risks and resources, work products and work schedule.
Modeling: Create a sketch, what it looks like architecturally,
how the constituent parts fit together and other characteristics.
Construction: code generation and the testing.
Deployment: Delivered to the customer who evaluates the
products and provides feedback based on the evaluation.

Umbrella Activities:- Complement the five process framework activities
and help team manage and control progress, quality, change, and risk.
Software project tracking and control: assess progress against
the plan and take actions to maintain the schedule.
Risk management: assesses risks that may affect the outcome
and quality.
Software quality assurance: defines and conduct activities to
ensure quality.
Technical reviews: assesses work products to uncover and
remove errors before going to the next activity.
Measurement: define and collects process, project, and product
measures to ensure stakeholders needs are met.
Software configuration management: manage the effects of
change throughout the software process.
Reusability management: defines criteria for work product
reuse and establishes mechanism to achieve reusable
components.
Work product preparation and production: create work products such as
models, documents, logs, forms and lists.
RAD model is Rapid Application Development model. It is a type of
incremental model. In RAD model the components or functions are
developed in parallel as if they were mini projects. The developments
are time boxed, delivered and then assembled into a working
prototype. This can quickly give the customer something to see and use
and to provide feedback regarding the delivery and their requirements.
The phases in the rapid application development (RAD) model are:
1.Business modeling: The information flow is identified between various
business functions. 2. Data modeling: Information gathered from
business modeling is used to define data objects that are needed for the
business. 3. Process modeling: Data objects defined in data modeling
are converted to achieve the business information flow to achieve some
specific business objective. Description are identified and created for
CRUD of data objects. 4 .Application generation: Automated tools are
used to convert process models into code and the actual system.
5. Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model: 1. Reduced development time.
2. Increases reusability of components 3. Quick initial reviews occur
4. Encourages customer feedback 5. Integration from very beginning
solves a lot of integration issues.
Disadvantages of RAD model: 1. Depends on strong team and individual
performances for identifying business requirements. 2. Only system that
can be modularized can be built using RAD 3. Requires highly skilled
developers/designers. 4. High dependency on modeling skills
5. Inapplicable to cheaper projects as cost of modeling and automated
code generation is very high.

The spiral model is a risk-driven process model generator for software
projects. Based on the unique risk patterns of a given project, the spiral
model guides a team to adopt elements of one or more process models,
such as incremental, waterfall, or evolutionary prototyping.

The basic idea here is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to
understand the requirements. This prototype is developed based on the
currently known requirements. By using this prototype, the client can get
an actual feel of the system, since the interactions with prototype can
enable the client to better understand the requirements of the desired
system. Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help
determining the requirements. The prototype are usually not complete
systems and many of the details are not built in the prototype. The goal is
to provide a system with overall functionality.
Advantages of Prototype model: 1.Users are actively involved in the
development. 2.Since in this methodology a working model of the
system is provided, the users get a better understanding of the system
being developed. 3.Errors can be detected much earlier. 4.Quicker user
feedback is available leading to better solutions. 5.Missing functionality
can be identified easily. 6.Confusing or difficult functions can be
identified Requirements validation, Quick implementation of,
incomplete, but functional, application.
Disadvantages of Prototype model: 1.Leads to implementing and then
repairing way of building systems. 2.Practically, this methodology may
increase the complexity of the system as scope of the system may
expand beyond original plans. 3.Incomplete application may cause
application not to be used as the full system was designed Incomplete or
inadequate problem analysis.

EMPIRICAL ESTIMATION MODELS: - An estimation model for computer
software uses empirically derived formulas to predict effort as a function
of LOC or FP. But instead of using the tables described in those sections,
the resultant values for LOC or FP are plugged into the estimation model.
The empirical data that support most estimation models are derived from
a limited sample of projects. For this reason, no estimation model is
appropriate for all classes of software and in all development
environments. Therefore, the results obtained from such models must be
used judiciously.
The overall structure of such models takes the form E = A + B x (ev)C
The COCOMO Model:- Barry Boehm introduced a hierarchy of software
estimation models bearing the name COCOMO, for COnstructive COst
MOdel. The original COCOMO model became one of the most widely
used and discussed software cost estimation models in the industry. It
has evolved into a more comprehensive estimation model, called
COCOMO II Like its predecessor, COCOMO II is actually a hierarchy of
estimation models that address the following areas: 1. Application
composition model. Used during the early stages of software
engineering, when prototyping of user interfaces, consideration of
software and system interaction, assessment of performance, and
evaluation of technology maturity are paramount. 2. Early design stage
model. Used once requirements have been stabilized and basic software
architecture has been established. 3. Post-architecture-stage model. Used
during the construction of the software.
NOP = (object points) x [(100 _ %reuse)/100] where NOP is defined as
new object points.
PROD = NOP/person-month
E = [LOC _ B0.333/P]3 _ (1/t4) (5-3)
where E = effort in person-months or person-years
t = project duration in months or years
B = special skills factor
P = productivity parameter
Tracking can be accomplished in a number of different ways:
1. Conducting periodic project status meetings in which each team
member Reports progress and problems.
2. Evaluating the results of all reviews conducted throughout the
software engineering Process.
3. Determining whether formal project milestones have been
accomplished by the scheduled date.
4. Comparing actual start-date to planned start-date for each
project task listed in the resource table.
5. Meeting informally with practitioners to obtain their subjective
assessment of Progress to date and problems on the horizon.
6. Using earned value analysis to assess progress quantitatively.
There are a number of qualitative approaches to project tracking. Each
provides the project manager with an indication of progress, but an
assessment of the information provided is somewhat subjective. It is
reasonable to ask whether there is a quantitative technique for assessing
progress as the software team progresses through the work tasks
allocated to the project schedule. In fact, a technique
for performing quantitative analysis of progress does exist. It is called
earned value analysis (EVA).

To determine the earned value, the following steps are performed:
1. The budgeted cost of work scheduled (BCWS) is determined for each
work task represented in the schedule.
2. The BCWS values for all work tasks are summed to derive the budget at
completion.
3. The value for budgeted cost of work performed (BCWP) is computed.
Schedule performance index, SPI = BCWP/BCWS
Schedule variance, SV = BCWP BCWS

Stakeholder - a person who has interested in how the system will work ie
product manager who wants that the system users share their activities
via social media, CTO who wants to have a five level security access to the
system etc. A stakeholder is a person or a group in an organization that
has a role in the development of the project for example end-user,
manager, engineer. There are thus three broad categories of
stakeholders: Those involved, affected or exerting influence. Examples of
those involved are the project manager, sponsor, and team members.
Those affected would be the users, community adjacent to the project,
etc. Those exerting an influence could be the media.
For system specification, nearly all information required for a description
of software scope is available and documented before software project
planning begins. In cases where a specification has not been developed,
the planner must take on the role of system analyst to determine
attributes and bounds that will influence estimation tasks. The System
Specification also describes the information (data and control) that is
input to and output from the system. The System Specification is the final
work product produced by the system and requirements engineer.
Types:-
1) Functional Specifications- Functional specifications
describe the necessary functions at the level of units
and components; these specifications are typically
used to build the system exclusive of the user
interface.
2) Design Specifications- The design specifications
address the look and feel of the interface, with rules
for the display of global and particular elements.
3) Technical Specifications- Technical specifications are
typically written the by developers and coders, and
describe how they will implement the project. The
developers work from the functional specifications,
and translate the functions into their actual coding
practices and methodologies.

THE ELEMENTS OF THE ANALYSIS MODEL:- The analysis model must
achieve three primary objectives: (1) to describe what the customer
requires, (2) to establish a basis for the creation of a software design, and
(3) to define a set of requirements that can be validated once the
software is built. Elements:- 1) At the core of the model lies the data
dictionarya repository that contains descriptions of all data objects
consumed or produced by the software. Three different diagrams
surround the the core.2) The entity relation diagram (ERD) depicts
relationships between data objects. 3) The data flow diagram (DFD)
serves two purposes: (1) to provide an indication of how data are
transformed as they move through the system and (2) to depict the
functions (and sub functions) that transform the data flow 4)The state
transition diagram (STD) indicates how the system behaves as a
consequence of external events. To accomplish this, the STD represents
the various modes of behavior (called states) of the system and the
manner in which transitions are made from state to state.
THE ELEMENTS OF BEHAVIORAL MODEL:- Behavioral modeling is an
operational principle for all requirements analysis methods. Yet, only
extended versions of structured analysis provide a notation for this type
of modeling. The state transition diagram represents the behavior of a
system by depicting its states and the events that cause the system to
change state. In addition, the STD indicates what actions (e.g., process
activation) are taken as a consequence of a particular event.
The User Interface Design Process: - The design process for user interfaces
is iterative and can be represented using a spiral Model. The user
interface design process encompasses four distinct framework activities-
1. User, task, and environment analysis and modeling
2. Interface design
3. Interface construction
4. Interface validation.

The Design Model: //connection To The Database

Uploaded by

Copyright:

Available Formats

The Design Model: //connection To The Database

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Design Model: //connection To The Database

Uploaded by

Copyright:

Available Formats

The design model

You might also like