Thursday 21 April 2022

Unified Process (UP) Best Practices

  • Get high risk and high value requirements first
  • Constant user feedback and engagement
  • Early cohesive core architecture
  • Test early, often, and realistically
  • Apply use cases where needed
  • Do some visual modeling with UML
  • Manage requirements and scope creep
  • Manage change requests and configuration

How to persist the selected value of the select box after form submit?

 <?php
if ($_POST['submit']) {
    if ($_POST['srf'] != "") {
        $srf = $_POST['srf'];
    } else {
        $srfErr = "This field is required.";
    }
}
?>
<form method="post">
<select name="srf" id="srf" class="form-control">
<option value="">Select</option>
<option <?php if (isset($srf) && $srf=="1") echo "selected";?>>1</option>
<option <?php if (isset($srf) && $srf=="2") echo "selected";?>>2</option>
<option <?php if (isset($srf) && $srf=="3") echo "selected";?>>3</option>
</select> <?php if($srfErr!= ""){ ?>
        <p><b><?php echo $srfErr;  ?></b></p>
</div>
    <?php }?>
<input type="submit" name="submit" value="submit" />
</form>

Unified Process Phases

Inception

  • Inception is not a requirements phase; rather a feasibility phase, where just enough investigation is done to support a decision to continue or stop. –
  • The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered. Scope and boundary conditions, acceptance criteria and some requirements are established.
  • Approximate vision, business case, scope, vague estimates.

Inception - Activities

  •  Formulate the scope of the project: Needs of every stakeholder, scope, boundary conditions and acceptance criteria established.
  •  Plan and prepare the business case: Define risk mitigation strategy, develop an initial project plan and identify known cost, schedule, and profitability trade-offs.
  • Synthesize candidate architecture: Candidate architecture is picked from various potential architectures
  • Prepare the project environment

Inception - Exit criteria

  • An initial business case containing at least a clear formulation of the product vision - the core requirements - in terms of functionality, scope, performance, capacity, technology base.
  • Success criteria (example: revenue projection).
  • An initial risk assessment.
  • An estimate of the resources required to complete the elaboration phase.

Elaboration

  • An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources. 
  • Refined vision, iterative implementation of core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates

Elaboration - Entry criteria

  • The products and artifacts described in the exit criteria of the previous phase. 
  • The plan approved by the project management, and funding authority, and the resources required for the elaboration phase have been allocated

Elaboration - Activities

  • Define the architecture: Project plan is defined. The process, infrastructure and development environment are described. 
  • Validate the architecture.  
  • Baseline the architecture: To provide a stable basis for the bulk of the design and implementation effort in the construction phase.

Elaboration - Exit criteria 
  • A detailed software development plan, with an updated risk assessment, a management plan, a staffing plan, a phase plan showing the number and contents of the iteration , an iteration plan, and a test plan
  • The development environment and other tools 
  • A baseline vision, in the form of a set of evaluation criteria for the final product.
  • A domain analysis model, sufficient to be able to call the corresponding architecture ‘complete’. 
  • An executable architecture baseline. 

Construction 

  • The Construction phase is a manufacturing process. It emphasizes managing resources and controlling operations to optimize costs, schedules and quality. This phase is broken into several iterations. 
  •  Iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. 

Construction - Entry criteria 
  • The product and artifacts of the previous iteration. The iteration plan must state the iteration specific goals
  • Risks being mitigated during this iteration. 
  • Defects being fixed during the iteration. 

Construction - Activities 
  • Develop and test components: Components required satisfying the use cases, scenarios, and other functionality for the iteration are built. Unit and integration tests are done on Components. 
  • Manage resources and control process. 
  • Assess the iteration: Satisfaction of the goal of iteration is determined.

Construction - Exit Criteria 
  • The same products and artifacts, updated, plus
  • A release description document, which captures the results of an iteration 
  • Test cases and results of the tests conducted on the products
  • An iteration plan, detailing the next iteration 
  • Objective measurable evaluation criteria for assessing the results of the next iteration(s).  

Transition 

  • The transition phase is the phase where the product is put in the hands of its end users. It involves issues of marketing, packaging, installing, configuring, supporting the user. community, making corrections, etc. 
  • Beta tests, deployment. 

Transition - Entry criteria
  • The product and artifacts of the previous iteration, and in particular a software product sufficiently mature to be put into the hands of its users.

Transition - Activities  
  • Test the product deliverable in a customer environment. 
  • Fine tune the product based upon customer feedback 
  • Deliver the final product to the end user 
  • Finalize end-user support material.

Transition - Exit criteria 
  • An update of some of the previous documents, as necessary, the plan being replaced by a “post-mortem” analysis of the performance of the project relative to its original and revised success criteria; 
  • A brief inventory of the organization’s new assets as a result this cycle.  


Wednesday 20 April 2022

ER [Entity–relationship] Model

ER Model is a popular high-level (conceptual) data model. It is an approach to designing Semantic Conceptual schema of a Database. ER model allows us to describe the data involved in a real-world environment in terms of objects and their relationships, which are widely used in design of database. ER model provides preliminary concepts or idea about the data representation which is later modified to achieve final detailed design.

Important concepts/notions used in ER modeling are-

Entity 

It is an object in real-world or some idea or concept which can be distinguished from other objects.

Ex.: person, school, class, department, weather, salary, temperature etc.

Entity has independent existence. 

Entity type

Each entity belongs to an Entity type that defines the structure.

Entity Set 

It is a Collection of similar objects.

Attribute

Reflects a property of an object or entity. We have following types of attributes.

> Simple attribute

> Composite attribute

> Single valued attribute

> Multi-valued attribute

> Derived attribute

> Stored attribute

Key

Is an Attribute of an entity type whose value can uniquely identify an entity in a set.

Relationship

The association between entities is known as relationship.

Domain of an attribute

The set of possible values is known as domain of an attribute



Degree of a Relationship

Degree is the number of entity type participate in a relationship. 
If there are two entity types involved it is a binary relationship type
eg: Manager manages employee

If there are three entity types involved it is a ternary relationship type  

Cardinality of a relationship

Relationships are rarely one-to-one. 
For example, a manager usually manages more than one employee. This is described by the cardinality of the relationship, for which there are four possible categories. 



The Agile Principles

1. Satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals.

6. The most efficient and effective method of conveying info. 

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development.

9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

10. Continuous attention to technical excellence and good design enhances agility.

11. Simplicity – the art of maximizing the amount of work NOT done is essential.

12. The best architectures, requirements, and designs emerge from self- organizing teams.

13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Data Model

Data Model is a collection of concepts that can be used to describe the structure of the database. Structure means data types, relationships, constraints etc. DBMS allows a user to define the data to be stored in terms of a data model. 

1.  High-level data models 

2.  Low-level data models

3. Representational or Implementation data models 

High-level Data Models

Use set of concepts to describe the database, where the descriptions are close to user views. High-level data models are also known as conceptual models. In conceptual data modeling we use concepts like – entity, attributes, relationship etc. 

Low-level Data Models

Give details about how the data is stored in a computers (storage level details).

Representational/Implementation Data Models

This is in between high-level and low-level data models. Here we represent the concepts described in conceptual model using a specific structures like, networks, objects, tables, trees etc. Ex: Relational Model, NW Model, Hierarchical Model, Object Model, Object relational model etc. 

Relational Model

The central data description construct in this model is a relation, which can be thought of as a set of records. 

Schema

Description of data in terms of a data model is called a schema. A relation schema specifies the name of the relation, fields, type etc. 

eg:. Student (sid: string; name: string; age: integer) every row follows the schema of the relation.

The following are some important representational data models (DBMS Specific) 

1. Network Model

Though the basic structure is a record, the relationships are captured using links. The database can be seen as an arbitrary network of records connected by links. Ex.: GE’s Integrated Data store (IDS), in Early 1960s 

2. Hierarchical Model 

The records containing data are organized as a collection of trees. Ex.: IBMs IMS (Information Management System), in late 1960s 

3. Relational Model (early 1970s)

Data & relationships are captured as tables & keys. Ex.: Oracle, IBMs DB2, MySQL, Informix, Sybase, MS Access, Ingress, MySQL etc. The basic storage structure is a record. 

4. Object Data Model

Objects created through object–oriented programs can be stored in database. Ex.: Object Store 

5. Object Relational Model

Objects can be stores in tables. Ex.: Oracle, Informix 

Database Schema

Description of a database is called as database Schema.

Three-Schema Architecture:

A database can be described using three different levels of abstractions. Description at each level can be defined by a schema. For each abstraction we focus on one of the specific issues such as user views, concepts, storage etc. 

1. External schema: Used to describe the database at external level. Also described in terms of the data model of that DBMS. This allows data access to be customized at the level of individual users/groups/applications. Any external schema has one or more views and relations from the conceptual schema. This schema design is guided by end user requirements. 

2. Conceptual schema (logical schema) Describes the stored data in terms of the data model specific to that DBMS. In RDBMS conceptual schema describes all relations that are stored in the database. Arriving at good choice of relations, fields and constraints is known as conceptual database design. 

3. Physical schema: Describes the physical storage strategy for the database.