28 November 2012

My Upwebhosting review Upwebhosting.com - Fraud

 My Upwebhosting review Upwebhosting.com - Fraud

Generally I am not in habit of posting such reviews but I don't want others to get fooled by the fake claims of upwebhosting.com so here is my upwebhosting review.

They have named themselves as upwebhosting.com but in actual they should be named as downwebhosting.com

My site is down from past 1 week. In-fact not just mine but sites of all other customers are down too from past 1 week.
Upwebhosting site was also down but is up now but my site is still down.

I have submitted serveral support tickets but never received any reply.
Today I found that I am not even unable to login to billing area. Perhaps this guy has closed the account.

Their facebook page is also full of such complaints. They have thousands of fake facebook likes on their page.

After some digging I found that upwebhosting also owns nexgenz.com (Nexgenz Technologies) and the owner of both sems to be a Pakistani named Wajahat Ali.

Hear I give give all my activities at upwebhosting.com

October 2, 2012: I take there reseller service.

October 3, 2012: They give me full control such WHM and Cpanel login details. they did take 4 days for setup.

October 3, 2012 - November 12, 2012: I was create three account. In this time one of site are go down and i open support ticket for solving problems but they don't replay for my maximum number of ticket.

November 13, 2012: I send email at info@upwebhosting.com for solving problems but they don't replay

upwebhosting.com Refund Policy

1. Our refund policy is valid for web hosting only, payment(s) made for domain registration are not refundable, however if a domain is not registered for any reason you will get a full refund

2. The 60 days refund policy applies to 1 year or above web hosting billing terms only

3. Refund can be requested by opening ticket, through phone or by sending email to: support@upwebhosting.com

4. Refund can be requested within 60 days after an order is placed, UpWebHosting will not ask for the reason of leaving

5. Refunds will be processed within 7 days after request is made.

November 22, 2012 : I was send email at info@upwebhosting.com, support@upwebhosting.com and open a support ticket for Give my Money Back and i think it may me it will take 7 days for processing purpose.

November 22, 2012 : i want to login my account at upwebhosting but i don't do this because they delete my account at upwebhosting.com

Do think 100 times before you think of sending even $1 to upwebhosting.com they are real fraud also there business and money back Guarantee

I have all document in my email, If any one need i will provide all

Please see another user review http://www.webhostingtalk.com/showthread.php?t=1204318

06 November 2012

DOS / Windows IP Commands

Below, you'll find a list of the most common IP commands for Windows and DOS. These include ipconfig, trace route, netstat, arp, route, hostname, control netconnections, and other popular DOS and Windows IP commands.
Display Connection Configuration: ipconfig /all

Display DNS Cache Info: ipconfig /displaydns

Flush and Reset DNS Cache: ipconfig /flushdns

Release All IP Address Connections: ipconfig /release

Renew All IP Address Connections: ipconfig /renew

Re-Register the DNS connections: ipconfig /registerdns

Change/Modify DHCP Class ID: ipconfig /setclassid

Network Connections: control netconnections

Network Setup Wizard: netsetup.cpl

Test Connectivity: ping domainname.com

Trace Route: tracert www.domainname.com

Displays the TCP/IP protocol sessions: netstat

Display Local Route: route

Display Resolved MAC Addresses: arp

Display Name of Computer Currently on: hostname

Display DHCP Class Information: ipconfig /showclassid

NameServer Lookup: nslookup domainname.com

***collected*** http://www.whatismyip.com

08 October 2012

change php settings using php.ini and .htaccess in cpanel

Due to the popularity of my previous post that guides how to increase upload_max_filesize on cPanel server I decided to create a more general article, that covers changing of other PHP settings using php.ini and.htaccess files.
In this article we will change the following php settings:
  • memory_limit – maximum amount of physical memory that can be allocated to PHP script
  • max_post_size – maximum size of data that can be transferred via POST method
  • register_globals – this variable allows to enable or disable register_globals
  • file_uploads – enables or disables file_uploads

10 September 2012

Download ja mendozite Templates Free

Tablet and Mobile (as default): support 2 modes, portrait and landscape.
Support 5 layouts (Extra-wide, wide, normal, tablet, mobile)
Multiple module styles and badges styles to choose from
Joomla 2.5.x compatible
Cross Browser Support: IE7+, Firefox 2+, Safari 3+, Chrome 8+, Opera 9+ and other Standards-Supporting Browsers.
Supports all mobile browsers
Valid 508 Accessibility
Well-commented css files flexible customization

Demo Link: Ja-mendozite-demo
Download Link: Ja-mendozite-download

23 June 2012

Changing mac address in windows registry

MAC-Address is the hardware Network Address for the NIC which is unique for the system. However, there may be time when you need to change the MAC-Address for administrative purpose on a network. Some of the device drivers come with an option to change it from the device properties but not all (like my Broadcom Gigabit Ethernet Driver). For those who do not have the luxury of changing the MAC-Address from the device properties there is a way to do this  by editing the Windows Registry.
To change MAC-Address for a Network card in Windows Registry:
1. Click Start – Run, type “regedit”
2. Navigate to
3. Under this key, you shoud see numbers in sequence as “0000″, “0001″ and so on. Click on one at a time to check the description of the device to match it with that of your Network Card. In my case (0001)

4. Once found, in the right-pane, look for “NetworkAddress” key value. If you find it, right-click and select modify. Enter the desired MAC-Address as a 12 digit number (all in one, no “space” “.” or “-”)
5. If you don’t find the key, right-click in the rightpane, select “New” – “String Value”. Enter the name as “NetworkAddress”. Now modify and set the desired value.
6. Now, disable and enable the Network card from the ControlPanel – Network Connections.
This should reflect the new MAC-Address on your NIC. Should you choose to go back to the original manufacturer set MAC-Address simply delete the key you just created/modified in the Windows Registry.

Source: http://www.windowsreference.com

18 June 2012


Right balance of technical skills and personalities, and organizing that group so that the members work together effectively.

Personality Type

  • Task-oriented -
    • The motivation for doing the work is the work itself.
    • who are motivated by the intellectual challenge of software development.
  • Self-oriented -
    • Who are principally motivated by personal success and recognition.
    • They are interested in software development as a means of achieving their own goals.
    • Have longer-term goals, such as career progression, that motivate them and they wish to be successful in their work to help realize these goals.
  • Interaction oriented -
    • The principal motivation is the presence and actions of co-workers.
    • People go to work because they like to go to work.

Most software engineering is a group activity The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. A good group is cohesive (solid) and has a team spirit. The people involved are motivated by the success of the group as well as by their own personal goals. Group interaction is a key determinant of group performance. Flexibility in group composition is limited Managers must do the best they can with available people

The People

The Stakeholders
  1. Senior manager – define business issues.
  2. Project (technical) manager – plan, motive, organize and control practitioners.
  3. Practitioners – deliver technical skill.
  4. Customers – specify the requirements.
  5. End user – directly interact with product.

Team Leaders
MOI Model of Leadership
  1. Motivation - The ability to encourage (by push or pull) technical people to produce to their best ability.
  2. Organization - The ability to mold exiting processes that will enable the initial concept to be translated into a final product.
  3. Ideas or innovation - The ability to encourage people to create and feel creativity
People Need Hierarchy

Characteristics of Team Leaders
  • Problem solving
    • Ability of diagnose the technical and organizational issues
    • Systematically structured solution or motivate practitioners to develop the solution
    • Apply lessons learned from past projects
  • Managerial Identity
    • Take responsibility of a assigned project
    • Must be confident
  • Achievement
    • Optimizing capability of productivity
  • Influence and team building
    • Able to “read” people
    • Able to understand verbal and nonverbal signals
    • Must remain under control in high-stress situations

Project Management

Projects need to be managed because professional software engineering is always subject to organizational budget and schedule constraints. The project manager’s job is to ensure that the software project meets and overcomes these constraints as well as delivering high-quality software.
Important goals are:
  1. Deliver the software to the customer at the agreed time.
  2. Keep overall costs within budget.
  3. Deliver software that meets the customer’s expectations.
  4. Maintain a happy and well-functioning development team.

Project Management Spectrum
  1. People
    1. Managing People
    2. Teamwork
  2. Product
  3. Process
  4. Project

02 June 2012

Class Diagram

  • The class diagram is a static diagram. It represents the static view of an application.Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application.
  • The class diagram describes the attributes and operations of a class.
  • The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community.
  • So the purpose of the class diagram can be summarized as:
    • Analysis and design of the static view of an application.
    • Describe responsibilities of a system.
    • Base for component and deployment diagrams.
    • Forward and reverse engineering.

Identifying Analysis Classes From a System:

  • General classifications for a potential class
    • External entity (e.g., another system, a device, a person)
    • Thing (e.g., report, screen display)
    • Occurrence or event (e.g., movement, completion)
    • Role (e.g., manager, engineer, salesperson)
    • Organizational unit (e.g., division, group, team)
    • Place (e.g., manufacturing floor, loading dock)
    • Structure (e.g., sensor, vehicle, computer)

Classes Hierarchy :

Classes Hierarchy

Example of Class Box :

Class Box

Class Diagram Drawing :

Class Diagram

Swim lane Diagram

  • Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle.
  • A swim lane diagram, sometimes called a cross-functional diagram.
  • It is a process flowchart that provides richer information on who does what.
  • It can also be expanded to show times—when tasks are done and how long they take.

Example :Swim lane Diagram for POS

Swim lane Diagram for POS

01 June 2012

Activity Diagrams

Activity Diagram Tools:

Activity Diagram Tools

Synchronization Bar:

A Synchronization Bar is used to describe an intermediary step in a process in an activity diagram.  This intermediary process re-establishes a logical level, usually the result of several inputs.

Example :Activity Diagram for Log in System

Activity Diagram for Log in System

Use Case Text

  • It is effective to use the first person “I” to describe how the actor interacts with the software.
  • Format of the text part of a use case.

Use-case title :
Use-case text for system user.

Actor : system user.

Description :I can add new member in this system also i can add a subject... ... ... ... ... ... ...


22 April 2012

Analysis Model

Elements of the Analysis Model

1. Scenario Based Element

2. Class Based Element
  • Class Diagram
  • Analysis Packages
  • CRC Models
  • Collaboration Diagrams
3. Flow Oriented elements
  • Data Flow Diagram
  • Control Flow Diagrams
  • Processing Narratives
4. Behavioral elements
  • State Diagrams
  • Sequence Diagrams
I will discuses all things one by one

20 April 2012

Software Analysis

Software analyses are dividing into five parts:
Objectives of analysis model
  • To describe what the customer require.
  • To establish a basis for the creation of a software design.
  • To define a set of requirements that can be validated once the software is built

    What is a model?
    Ans:a model is a simplification of reality

    Why do we model?
    -we build models so that we can better understand the system we are developing.
    -we build models of complex systems because we cannot comprehend such a system in its entirety.
    -four aims to achieve:-
    1. help us to visualize a system.
    2. permit us to specify the structure/behavior of a system.
    3. give us a template that guides us in constructing systems.
    4.document the decisions we have made.

11 April 2012

Use Case Diagrams

Use Case Diagrams:

  • A use case in software engineering and systems engineering is a description of a system’s behavior.
  • In other words, a use case describes "who" can do "what" with the system in question.
  • The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.


  • An actor represents a set of roles that users of use case play when interacting with these use cases.
  • Actors can be human or automated systems.
  • Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions.

Use Case Diagram for School Management

Fig: Use Case Diagram for School Management

Use Case Diagram for Point of Sale

Fig: Use Case Diagram for Point of Sale

07 April 2012

Requirement Management

Traceability Tables

Features traceability table:
Shows how requirements relate to important customer observable system/product features.
Source traceability table:
Identifies the source of each requirement.
Dependency traceability table:
Indicates how requirements are related to one another.
Subsystem traceability table:
Categorizes requirements by the subsystem(s) that they govern.
Interface traceability table:
Shows how requirements related to both internal and external system interfaces.

Steps of Requirement Engineering

  • Inception: define scope and nature
    •  How does a software project will started
    •  Define business plan
    • Identify breath and depth of market
    • Rough feasibility analysis
    • Identify working description
  • Elicitation: help customer to define what is required
    • Time to come out
    • Problem of scope
      • Boundary, avoid unnecessary technical details
    • Problem of understanding
      • Not sure about need
    • Problem of volatility
      • Requirement changing
  • Elaboration: basic requirements are found and modified
    • Inception and elicitation expanded and refined
    • It is analysis modeling action
    • Relationship and collaboration between classes are identified and generate use case diagram
  • Negotiation: priorities, what is essential, what is required to maintain –defined
    • Ahead to analysis
    • Cost estimation, delivery time, elimination - combination – modification of requirements
  • Specification: problems are specified
    • Written document
    • Set of graphical or mathematical model
    • Collection of scenario
    • Prototype of combination of these
  • Validation: customer concept and the software functional behaviors are same or not - defined
    • Examine all requirements are fulfilled and understood
    • Formal technical review

What is Non-functional requirements

  • These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
    i.e. Deactivate or delete record after 24 hrs
  • Process requirements may also be specified mandating a particular programming language or development method.
  • Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

Types of Nonfunctional requirement

Product requirement: Examples
The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.

Organizational requirement: Examples
Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.

External requirement: Examples
The system shall implement patient privacy.

Non-functional requirements implementation

  • Non-functional requirements may affect the overall architecture of a system rather than the individual components.
    • For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.

What is Functional requirements

  • Describe functionality or system services.
  • Depend on the type of software, expected users and the type of system where the software is used.
  • Functional user requirements may be high-level statements of what the system should do.
  • Functional system requirements should describe the system services in detail.

Examples: Functional requirements for the MHC-PMS

  • A user shall be able to search the appointments lists for all clinics.
  • The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.
  • Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

Requirements imprecision

  • Problems arise when requirements are not precisely stated.
  • Ambiguous requirements may be interpreted in different ways by developers and users.
  • Consider the term ‘search’ in requirement 1
    • User intention – search for a patient name across all appointments in all clinics;
    • Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search.

Requirements completeness and consistency

  • In principle, requirements should be both complete and consistent.
    • Complete-They should include descriptions of all facilities required.
    • Consistent-There should be no conflicts or contradictions in the descriptions of the system facilities.
  • In practice, it is impossible to produce a complete and consistent requirements document.

Types of requirement

User requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirements
A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

May state what the system should not do.

Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Often apply to the system as a whole rather than individual features or services.

29 March 2012

What is Requirement Engineering

What is Requirement?
Ans: It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. Its Begin from Communication and continues into the modelling.

What is Requirement Engineering?
  • The process of establishing the services that the customer requires from a system and the constraintunder which it operates and is developed.
  • Requirement reflects the needs of customer for a system that serves a certain purpose such as controlling a device, placing an command or finding information.
  • The process of finding out, analyzing, documenting and checking these services and constrains is called requirement engineering (RE).
  • Bridge to design and construction.
Example of Types of Requirement

Testing and Deployment Principles

Testing Principles
  • All tests should be traceable to customer requirements
  • Tests should be planned long before testing begins
  • Testing should begin “in the small” and progress toward testing “in the large”
Deployment Principles
  • Customer expectation for the software must be managed
  • A complete delivery package should be assembled and tested
  • A support government must be established before the software is delivered
  • Appropriate instructional materials must be provide to end user
  • Buggy software should be fixed first, delivered later

Coding principles for Software Project

Preparation : Before writing code

  • Understand the problem you’re trying to solve
  • Understand basic design principles and concepts
  • Pick a programming language that meets the need s of the software to be built and the environment in which it will operate
  • Create a set of unit tests that will be applied once the coding is complete for each component

Coding: When writing code

  • Constrain your algorithm by following structured programming practice
  • Select the data structure that will meet the needs of design
  • Understand the software architecture and create interfaces that are consistent with it
  • Select meaningful variable name
  • Create visual layout

Modeling Principles for Software Project

Analysis Modelling Principles
  1. The information domain of a problem must be represented
  2. The functions that the software performs must be defined
  3. The behaviour of the software must be represented
  4. The models that depict information, function and behaviour must be partitioned is a manner that uncovers detail a layered or hierarchical fashion
  5. The analysis task should move from essential information toward implementation detail
Design Modelling Principles
  1. Design should be traceable to the analysis model
  2. Always consider the architecture of the system to be built
  3. Design of data is as important as design of processing functions
  4. Interface must be designed with care
  5. Component level design should be functionally independent
  6. Design representation should be easily understandable
  7. The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity

Planning Principles for Software Project

  1. Understand the scope of the project
  2. Involve the customer in the planning activities
  3. Recognize that planning is iterative
  4. Estimate based on what you know
  5. Consider risk as you define the plan
  6. Be realistic
  7. Define how you intend to ensure quality
  8. Track the plan frequently and make adjustment as required

Software Engineering Practice

  • Understand the problem (communication and analysis)
  • Plan a solution (modelling and software design)
  • Carry out the plan (code generation)
  • Examine the result for accuracy (testing and quality assurance)
Core principles for Software Engineering :
  • The reason it all exists
  • KISS! (Keep It Simple Stupid)
  • Maintain the vision
  • Be open to the future
  • Plan ahead for reuse
  • Think!

what is communication

Main Business Communication principles

Business communication is the communication between the people in the organization for the purpose of carrying out the business activities.

A business can flourish when all objectives of the organization are achieved effectively. For efficiency in an organization, all the people of the organization must be able to convey their message properly.

The exchange of ideas and understanding within and outside the organization to achieve the business goals is known as business communication.

Communication Skills Needed in Business

  • Speaking well
  • Writing well
  • Displaying proper etiquette (manners)
  • Listening attentively

The Basic Forms Of Communication

  • Nonverbal communication:
    • Facial
    • Gesture
    • Vocal characteristic
    • Personal appearance
    • Touching behavior
    • Use time and space
  • Verbal Communication:
    • speaking and writing
    • Listening and Reading


Why Business Needs to Communicate?

  • Communication is vital to every part of business.
Example for Employees:
- process information with computers,
- write messages,
- fill out forms,
- give and receive orders, and
- talk over the telephone.

Example for Executives:
- use written and oral messages to initiate business with customers and other companies and
- respond to incoming messages.

Oral communication is a major part of information flow.

Written communication:
- letters,
- email messages,
- memos
- reports, and
- internet documents.

Characteristics Of Effective Organizational Communication

  • An Open Communication Climate.
  • A Commitment to Ethical Communication.
  • An understanding of Intercultural Communication.
  • A Proficiency in Communication Technology.
  • An Efficient Flow of Communication Message.

Communication Network of the Organization

Two forms of network in an organization: 1) Formal. 2) Informal

Formal: The business has major, well-established channels of information flow. These are the formal channels – the main lines of operational communication (both internal and external). Specifically, the flow includes the:
- upward,
- horizontal (lateral), and
- downward movements of information by
- report,
- email,
- records and
- such within the organization.

It also includes:
- orders, instructions, and messages: down the authority structure;
- working information: through the organization’s email or intranet; and
- extremely directed messages: sales presentations, advertising, and publicity.

Informal:The informal network is a secondary network consisting primarily of personal communication. It comprises thousands of personal communications that support the formal communication network of a business. Informal network is not a single network but a smaller networks consisting of groups of people.

it carries much gossip and rumor, for this is the nature of human conversation. Wise managers recognize the presence of the grapevine. That is, they keep in touch with the grapevine and turn it into a constructive tool.

Communication Barriers between People:

  • Difference in perception.
  • Incorrect filtering.
  • Language problem.
  • Poor listening.
  • Different emotional states.
  • Different background.

Communication Barriers between Organization:

  • Information Overload
  • Inattention
  • Time pressure
  • Distraction/Noise
  • Emotions
  • Complexity of Organizational structure
  • Poor retention
  • Differing Status
  • Lack Of Trust
  • Inadequate communication structure
  • Incorrect Choice Of Medium
  • Closed communication Climate

How To Improve Communication skills

A Good Communicator should have these five traits:
  1. Perception.
  2. Precision.
  3. Credibility.
  4. Control.
  5. Congeniality.

Importance of Business Communication to you and for Business

  • High communication skill and leads high income.
  • Improving your commutation ability helps to improve your overall success.
  • Communication is vital to every part of business.
  • Different professional use communication as a tool to correspond with their colleagues, superiors and juniors.
  • Business managers use communication to contact their stakeholders.
  • Information is managed and exchanged thorough many oral, written and electronic form.

28 March 2012

What is software engineering

1.What is software?

Ans:Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.

2.What is software engineering?

Ans:Software engineering is an engineering discipline that is concerned with all aspects of software production.

3.What is the difference between software engineering and system engineering?

Ans:System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process

4.What are the key challenges facing software engineering?

Ans:Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software.

5.What are the costs of software engineering?

Ans:Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

6.What are the best software engineering techniques and methods?

Ans:While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another.

7.What differences has the web made to software engineering?

Ans:The web has led to the availability of software services and the possibility of developing highly distributed service-based systems. Web-based systems development has led to important advances in programming languages and software reuse.

8.What are the attributes of good software?

Ans:Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.

9.What is the difference between software engineering and computer science?

Ans:Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

10.What are the fundamental software engineering activities?

Ans:Software specification, software development, software validation and software evolution.

26 March 2012

The Rational Unified Process Model

Rational Unified Process:
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:
  • Stakeholder concurrence on scope definition and cost/schedule estimates.
  • Requirements understanding as evidenced by the fidelity of the primary use cases.
  • Credibility of the cost/schedule estimates, priorities, risks, and development process.
  • Depth and breadth of any architectural prototype that was developed.
  • Establishing a baseline by which to compare actual expenditures versus planned expenditures.
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

The outcome of the elaboration phase is:

  • A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed.
  • The use-case model should be 80% complete.
  • A description of the software architecture in a software system development process.
  • An executable architecture that realizes architecturally significant use cases.
  • Business case and risk list which are revised.
  • A development plan for the overall project. Prototypes that demonstrably mitigate each identified technical risk.
  • A preliminary user manual (optional)
This phase must pass the Lifecycle Architecture Milestone criteria answering the following questions:
  • Is the vision of the product stable?
  • Is the architecture stable?
  • Does the executable demonstration indicate that major risk elements are addressed and resolved?
  • Is the construction phase plan sufficiently detailed and accurate?
  • Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
  • Is the actual vs. planned resource expenditure acceptable?
If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.
The key domain analysis for the elaboration is the system architecture.

The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase.
If all objectives are met, the Product Release Milestone is reached and the development cycle is finished.

•Develop software iteratively
–Plan increments based on customer priorities and deliver highest priority increments first.

•Manage requirements
–Explicitly document customer requirements and keep track of changes to these requirements.

•Use component-based architectures
–Organize the system architecture as a set of reusable components.

•Visually model software
–Use graphical UML models to present static and dynamic views of the software. 

•Verify software quality
–Ensure that the software meet’s organizational quality standards.

•Control changes to software
–Manage software changes using a change management system and configuration management tools.

You can also view:
1. Boehms Spiral Process Model
2. Rapid Application Development-RAD
3. Prototyping Process Model
4. Incremental Process Model
5. Component Based Software Engineering
6. Evolutionary Process Development Model
7. Waterfall Process Model
8. Software Process Framework Activity

Boehm’s Spiral Process Model

Spiral model:
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral life-cycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement". This model was not the first model to discuss iterative development. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. 

 •Objective setting
-Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management  plan  is  drawn  up.  Project  risks  are  identified.  Alternative  strategies, depending on these risks, may be planned.

 •Risk assessment and reduction
-For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.

 •Development and validation
-After risk evaluation, a development model for the system is chosen. For example, throwaway prototyping may be the best development approach if user interface risks are dominant. If safety risks are the main consideration, development based on formal transformations may be the most appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model may be the best development model to use.
-The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.

•Main characteristics
 –Also a hybrid model that support process iteration.
–The process is represented as a spiral, each loop in the spiral representing a process phase.
–Risk is explicitly taken into consideration.

–Risk reduction mechanisms are in place.
–Supports iteration and reflects real-world practices –Systematic approach.

–Requires expertise in risk evaluation and reduction.
–Complex, relatively difficult to follow strictly.
–Applicable only to large systems

–Internal development of large systems.

You can also view:
1. Rational Unified Process Model.
2. Rapid Application Development-RAD
3. Prototyping Process Model
4. Incremental Process Model
5. Component Based Software Engineering
6. Evolutionary Process Development Model
7. Waterfall Process Model
8. Software Process Framework Activity

Rapid Application Development (RAD)

RAD, or rapid application development, is an object-oriented approach to systems development that includes a method of development as well as software tools

•RAD is used when
–The team includes programmers and analysts who are experienced with it.
–Users are sophisticated and highly engaged with the goals of the company.

•Negative Aspect
- RAD is based on Object Oriented approach.
- If commitment is lacking RAD will fail.
- RAD is not appropriate when technical risks are high, e.g. this occurs when a new application makes heavy use of new technology.

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

The Prototyping Process Model

•Gather requirements
•Quick design focusing on what will be visible to user – input & output formats
•Process iterated until customer & developer satisfied

– then throw away prototype and rebuild system to high quality.
- Insufficient analysis.
- Excessive development time of the prototype.
- High expectations for productivity with insufficient effort.

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

The Incremental Process Model

•Main characteristics
–Hybrid model that combines elements of the waterfall and evolutionary paradigms.
–The specification, design, and implementation phases are broken in smaller increments.

–Provides better support for process iteration.
–Reduces rework in the software construction process.
–Allows early delivery of parts of the system.
–Supports easier integration of sub-systems.
–Lower risk of project failure.
–Delivery priorities can be more easily set.

–Mapping requirements to increments may not be easy.
–Common software facilities may be difficult to identify.
–Some decisions on requirements may be delayed.

–When it is possible to deliver the system “part-by-part” .

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

Component Based Software Engineering

•Main characteristics
–Makes intensive use of existing reusable components.
–The focus is on integrating the components rather than on creating them from the scratch.

–Reduces considerably the software to be developed “in-house”.
–Allows faster delivery.
–In principle, more reliable systems, due to using previously tested components.

–agreement in requirements are needed.
–Less control over the system’s evolution

–When there is a pool of existing components that could satisfy the requirements of the new product.
–Emerging trend: integration of web services from a range of suppliers.

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

25 March 2012

The Evolutionary Process Development Model

•Main characteristics
–Feedback from the user is used throughout the entire process.
–The software product is refined through many versions

–Deals constantly with changes.
–Provides quickly an initial version of the system.
–Involves all development teams

–Quick fixes may be involved
–“Invisible” process, not well-supported by documentation.
–The system’s structure can be corrupted by continuous change.

•Disadvantages [cont’d]
–Special tools and techniques may be necessary
–The client may have the impression the first version is very close to the final product and thus be less patient.

–When requirements are not well understood.
–Good for small and medium-sized software systems.

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

The Waterfall Process Model

•Main characteristics:
–Also called classic software life cycle or sequential model
–Process activities (phases/stages) are clearly separated

–Organized approach, provides robust separation of phases.
–Reflects common engineering practice.

– Doesn't cope well with changes required by the client.
–Development teams might wait for each other.
–A working version of the product is available only late.

–When requirements are well known and few changes are likely to be needed.
–Can be used also for parts of larger software systems.

You can also view:
1. Boehms Spiral Process Model
2. Rational Unified Process Model
3. Rapid Application Development-RAD
4. Prototyping Process Model
5. Incremental Process Model
6. Component Based Software Engineering
7. Evolutionary Process Development Model
8. Waterfall Process Model
9. Software Process Framework Activity

what is Software process descriptions

•When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities.

•Process descriptions may also include:

–Products, which are the outcomes of a process activity;

–Roles, which reflect the responsibilities of the people involved in the process;

–Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.

Software Process Models

•A structured set of activities required to develop a software system.
•Many different software processes but all involve:

–Specification – defining what the system should do;

–Design and implementation – defining the organization of the system and implementing the system;

–Validation – checking that it does what the customer wants;

–Evolution – changing the system in response to changing customer needs.

Software Process Framework Activity

Layered Technology of Software Engineering

•For establish the sound engineering principles we have to ensure the layers of S/W engineering:

Quality Focus
At first ensure the professional quality

Enable timely delivery through framework and work products(models, docs, report etc.)
Ensure technical method
Ensure the model and change is properly managed

Define “how to” ’s and define broad array of tusks
Include communication, analysis, designing, program construction, testing and support.

Provide support for the process and method.

Software engineering Ethics Issues of Professional Responsibility

–Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.

–Engineers should not misrepresent their level of competence. They should not knowingly accept work which is out with their competence.

•Intellectual property rights
–Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.

•Computer misuse
–Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

what is Software engineering Ethics

Like other engineering disciplines,  Software engineering is carried out within a social and legal framework that limits the freedom of people working in that area. As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills. You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer.

 It goes without saying that you should uphold normal standards of honesty and integrity. You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession. However, there are areas where standards of acceptable behavior are not bound by laws but by the more tenuous notion of professional responsibility.

Some of these are:
1. Confidentiality You should normally respect the confidentiality of your employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.
2. Competence You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence.
3. Intellectual property rights You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected.
4. Computer misuse You should not use your technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses or other malware).

Other Hand:
Software engineering involves wider responsibilities than simply the application of technical skills.

• Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals.

• Ethical behavior is more than simply upholding the law but involves following a set of principles that are morally correct.

Content are helpful for you?

Follow by Email