Mikeem's Favorite Links on exam from Diigo

Index of /faculty/chinneck/po

Fri, 21 Dec 2007 08:15:38 -0000

Tags: exam good maths resource

Posted by: mikeem

Introduction to Operations Research ... - Google Book Search

Fri, 21 Dec 2007 00:05:32 -0000

Tags: exam linear maths operations programming

Posted by: mikeem

Tutorial for the Simplex Method: Non-Standard Problems

Thu, 20 Dec 2007 19:56:38 -0000

Tags: dual exam maths simplex tutorial

Posted by: mikeem

www.whitezoo.com - /whitezoofiles/maths/a-level/D1 teaching notes/

Wed, 19 Dec 2007 22:34:26 -0000

Tags: exam goodfind maths presentations

Posted by: mikeem

Software Development Methodology

Wed, 19 Dec 2007 08:15:10 -0000

Highlights and Sticky Notes:

Spiral Methodology:

While the waterfall methodology offers an orderly structure for software development, demands for reduced time-to-market make its series steps inappropriate. The next evolutionary step from the waterfall is where the various steps are staged for multiple deliveries or handoffs. The ultimate evolution from the water fall is the spiral, taking advantage of the fact that development projects work best when they are both incremental and iterative, where the team is able to start small and benefit from enlightened trial and error along the way.

The spiral methodology reflects the relationship of tasks with rapid prototyping, increased parallelism, and concurrency in design and build activities. The spiral method should still be planned methodically, with tasks and deliverables identified for each step in the spiral.

Waterfall Methodology

All projects can be managed better when segmented into a hierarchy of chunks such as phases, stages, activities, tasks and steps. In system development projects, the simplist rendition of this is called the "waterfall" methodology, as shown in the following figure:

In looking at this graphic, which was for major defense systems developments, please note this presumes that the system requirement have already been defined and scrubbed exhaustively, which is probably the most important step towards project success. Nevertheless, the graphic illustrates a few critical principles of a good methodology:

Work is done in stages,
Content reviews are conducted between stages, and
Reviews represent quality gates and decision points for continuing.

The waterfall provides an orderly sequence of development steps and helps ensure the adequacy of documentation and design reviews to ensure the quality, reliability, and maintainability of the developed software. While almost everyone these days disparages the "waterfall methodology" as being needlessly slow and cumbersome, it does illustrate a few sound principles of life cycle development.

Tags: development exam methodology software waterfall

Posted by: mikeem

Software Process Models

Wed, 19 Dec 2007 08:14:00 -0000

Highlights and Sticky Notes:

It is very important to gather all possible requirements during the first phase of requirements collection and analysis. If not all requirements are obtained at once the subsequent phases will suffer from it. Reality is cruel. Usually only a part of the requirements is known at the beginning and a good deal will be gathered during the complete development time.
Iterations are only meant to happen within the same phase or at best from the start of the subsequent phase back to the previous phase. If the process is kept according to the school book this tends to shift the solution of problems into later phases which eventually results in a bad system design. Instead of solving the root causes the tendency is to patch problems with inadequate measures.
There may be a very big "Maintenance" phase at the end. The process only allows for a single run through the waterfall. Eventually this could be only a first sample phase which means that the further development is squeezed into the last never ending maintenance phase and virtually run without a proper process.

The disadvantages of the spiral model are that the risk assessment is rigidliy anchored in the process. First of all it demands risk-assessment expertise to perform this task and secondly in some cases the risk assessment may not be necessary in this detail. For completely new products the risk assessment makes sense. But I dare to say that the risks for programming yet another book keeping package are well known and do not need a big assessment phase. Also if you think of the multitude of carry over projects in many industries i.e. applying an already developed product to the needs of a new customer by small changes, the risks are not a subject generating big headaches. Generally speaking the spiral model is not much esteemed and not much used, although it has many advantaged and could have even more if the risk assessment phases would be tailored down to the necessary amount.

Tags: advantage development exam software

Posted by: mikeem

» Waterfall? Spiral? Who cares? - DevChix - Blog Archive

Wed, 19 Dec 2007 08:12:05 -0000

Highlights and Sticky Notes:

The waterfall and the spiral and other formal models such as the “surgeon” don’t model real-world software development very well because they ignore the impact of communication skills. The agile methods do not. XP, for example, sets up a formal channel of communication between the customer and the programmers. It also sets channels within the programming team via pair programming, nightly check-ins, and automated builds.

Tags: exam waterfall xp

Posted by: mikeem

Project Lifecycle Models: How the differ and when to use them

Wed, 19 Dec 2007 08:10:49 -0000

Highlights and Sticky Notes:

Pure Waterfall

This is the classical system development model. It consists of discontinuous phases:

Concept
Requirements
Architectural design
Detailed design
Coding and development
Testing and implementation

Strengths	Weaknesses
Minimizes planning overhead since it can be done up front. Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.	Inflexible Only the final phase produces a non-documentation deliverable. Backing up to address mistakes is difficult.

Pure Waterfall Summary
The pure waterfall performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. It's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.

Spiral

The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:

Determine objectives, alternatives and constraints.
Identify and resolve risks.
Evaluate alternatives.
Develop the deliverables for that iteration and verify that they are correct.
Plan the next iteration.
Commit to an approach for the next iteration.

Strengths	Weaknesses
Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as costs increase, risks decrease. Each iteration of the spiral can be tailored to suit the needs of the project.	It is complicated and requires attentive and knowledgeable management to pull it off.

Spiral Summary
For projects with risky elements, it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle.

Tags: exam lifecycle project spiral waterfall

Posted by: mikeem

Waterfall - Software Development Model

Wed, 19 Dec 2007 08:09:54 -0000

Tags: development exam software waterfall

Posted by: mikeem

What is the diff. Between Waterfall and Spiral model?

Wed, 19 Dec 2007 08:07:32 -0000

Highlights and Sticky Notes:

# 2

In the water fall model the process flows from top to 
bottom like a flow of water . But any new changes can not 
be incorporated in the middle of the project development.

Whereas the spiral model is best suted for projects 
associated with risks.

The waterfall model the process goes to the next step after completion of the previous step as first requirement then design then coding then implementation then maintenance but here is no end user feedback taken to consideration any change in SRS will result to start work fro first step and goes step by step again. But in case of Spiral model for each and every step there is testing for that step carry on simultaneously after finishing that step so that it will easy to recover any error and fix it there. In this model we don?t have to start work from beginning

Tags: exam spiral waterfall

Posted by: mikeem

The Waterfall Model Explained

Wed, 19 Dec 2007 08:06:30 -0000

Highlights and Sticky Notes:

The Waterfall Model Explained

Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model"

Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

disadvantages of the Waterfall Model.
1) As it is very important to gather all possible requirements during the Requirement Gathering and Analysis phase in order to properly design the system, not all requirements are received at once, the requirements from customer goes on getting added to the list even after the end of "Requirement Gathering and Analysis" phase, this affects the system development process and its success in negative aspects.

2) The problems with one phase are never solved completely during that phase and in fact many problems regarding a particular phase arise after the phase is signed off, this results in badly structured system as not all the problems (related to a phase) are solved during the same phase.

3) The project is not partitioned in phases in flexible way.

4) As the requirements of the customer goes on getting added to the list, not all the requirements are fulfilled, this results in development of almost unusable system. These requirements are then met in newer version of the system; this increases the cost of system development.

Tags: development exam methods software waterfall

Posted by: mikeem

Picture Image: Spiral Model - A New Approach Towards Software Development

Wed, 19 Dec 2007 08:03:34 -0000

Highlights and Sticky Notes:

Tags: development exam software spiral

Posted by: mikeem

Spiral Model - A New Approach Towards Software Development

Wed, 19 Dec 2007 08:00:12 -0000

Highlights and Sticky Notes:

The Waterfall model is the most simple and widely accepted/followed software development model, but like any other system, Waterfall model does have its own pros and cons. Spiral Model for software development was designed in order to overcome the disadvantages of the Waterfall Model.

Waterfall Model" has its own disadvantages such as there is no fair division of phases in the life cycle, not all the errors/problems related to a phase are resolved during the same phase, instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase, this takes much of time of the next phase to solve them. The risk factor is the most important part, which affects the success rate of the software developed by following "The Waterfall Model".

In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it. This model is referred as "The Spiral Model" or "Boehm’s Model".

four phases in the "Spiral Model" which are:

Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle.

Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.

Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same.

Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to TESTING phase.

process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration almost all possible risk factors, constraints, requirements are identified

The Spiral Model" does have its pros and cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task.

Tags: development exam programming spiral waterfall

Posted by: mikeem

Understanding the pros and cons of the Waterfall Model of software development

Wed, 19 Dec 2007 00:49:53 -0000

Highlights and Sticky Notes:

Overview

Waterfall development isn't new -- it's been around since 1970 -- but most developers still only have a vague idea of what it means. Essentially, it's a framework for software development in which development proceeds sequentially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance. Feedback loops exist between each phase, so that as new information is uncovered or problems are discovered, it is possible to "go back" a phase and make appropriate modification. Progress "flows" from one stage to the next, much like the waterfall that gives the model its name.

six distinct phases, described below:

Requirements analysis: This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve. Analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification,

Design: This step consists of "defining the hardware and software architecture, components, modules, interfaces, and data...to satisfy specified requirements" (Wikipedia). It involves defining the hardware and software architecture, specifying performance and security parameters, designing data storage containers and constraints, choosing the IDE and programming language, and indicating strategies to deal with issues such as exception handling, resource management and interface connectivity.

also the stage at which user interface design is addressed, including issues relating to navigation and accessibility. The output of this stage is one or more design specifications, which are used in the next stage of implementation.

Implementation: This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements.

Testing: In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step. An independent quality assurance team defines "test cases" to evaluate whether the product fully or partially satisfies the requirements outlined in the first step. Three types of testing typically take place: unit testing of individual code modules; system testing of the integrated product; and acceptance testing, formally conducted by or on behalf of the customer.

Installation: This step occurs once the product has been tested and certified as fit for use, and involves preparing the system or product for installation and use at the customer site

the deliverable is typically tagged with a formal revision number to facilitate updates at a later date.

Maintenance: This step occurs after installation, and involves making modifications to the system or an individual component to alter attributes or improve performance. These modifications arise either due to change requests initiated by the customer, or defects uncovered during live use of the system. Typically, every change made to the product during the maintenance cycle is recorded and a new product release (called a "maintenance release" and exhibiting an updated revision number) is performed to enable the customer to gain the benefit of the update.

Advantages

The waterfall model, as described above, offers numerous advantages for software developers. First, the staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met.

Getting the requirements and design out of the way first also improves quality; it's much easier to catch and correct possible flaws at the design stage than at the testing stage, after all the components have been integrated and tracking down specific errors is more complex. Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when team members are dispersed in different locations.

Criticisms

Despite the seemingly obvious advantages, the waterfall model has come in for a fair share of criticism in recent times. The most prominent criticism revolves around the fact that very often, customers don't really know what they want up-front; rather, what they want emerges out of repeated two-way interactions over the course of the project. In this situation, the waterfall model, with its emphasis on up-front requirements capture and design, is seen as somewhat unrealistic and unsuitable for the vagaries of the real world. Further, given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult. In general, therefore, the model is recommended for use only in projects which are relatively stable and where customer needs can be clearly identified at an early stage.

Another criticism revolves around the model's implicit assumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation. Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model. Some criticisms also center on the fact that the waterfall model implies a clear division of labor between, say, "designers", "programmers" and "testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient.

Customer needs

While the model does have critics, it still remains useful for certain types of projects and can, when properly implemented, produce significant cost and time savings. Whether you should use it or not depends largely on how well you believe you understand your customer's needs, and how much volatility you expect in those needs as the project progresses. It's worth noting that for more volatile projects, other frameworks exists for thinking about project management, notably the so-called spiral model...but that's a story for another day!

Tags: development exam software waterfall

Posted by: mikeem

Software Development Today

Wed, 19 Dec 2007 00:45:02 -0000

Highlights and Sticky Notes:

Many years ago in 1970, Winston Royce wrote an article where he described (and warned about) the use of the one-pass waterfall ("waterfall" for short). In that article Royce states that if the waterfall was to be used, it should be a "multi-pass" waterfall with many feedback cycles between the different phases, where when you pass through a phase (be it requirements, design or any of the other 7 phases Royce defined in his paper) you learn more about the previous phase and should include that feedback by re-iterating the previous phase.

Later, in 1988, Barry Bohem, also known for his work in the domain of Risk Management came up with the Spiral model of development. This process improvement wave introduced the concept that you do a little bit of everything as you go (e.g. early prototyping), and you repeat often. There was little talk of releasing working software often and interacting with customers, but this was a big push towards the "incremental" process model.

Tags: development exam software waterfall

Posted by: mikeem

Image:Overview of a three-tier application.png - Wikipedia, the free encyclopedia

Tue, 18 Dec 2007 21:56:22 -0000

Highlights and Sticky Notes:

No higher resolution available.
Overview_of_a_three-tier_application.png‎ (596 × 536 pixels, file size: 76 KB, MIME type: image/png)

Tags: architecture exam multi tier

Posted by: mikeem

Multitier architecture - Wikipedia, the free encyclopedia

Tue, 18 Dec 2007 21:55:21 -0000

Highlights and Sticky Notes:

Web Development usage

In the Web development field, three-tier is often used to refer to Websites, commonly Electronic commerce websites, which are built using three tiers:

A front end Web server serving static content
A middle dynamic content processing and generation level Application server, for example Java EE platform.
A back end Database, comprising both data sets and the Database management system or RDBMS software that manages and provides access to the data.

Three Tier Architecture (Linux journal) [1]

Tags: architecture exam multi tier

Posted by: mikeem

Multitiered Architectures (Linktionary term)

Tue, 18 Dec 2007 21:54:01 -0000

Highlights and Sticky Notes:

Multitiered architectures are software models (and hardware models, as discussed later) that extend the basic two-tiered client/server model to three tiers. In the basic two-tiered client/server model, the client requests services and the server provides services. There are software interfaces on the client and the server side that connect with one another to handle these interactions.

However, the two-tiered model has some drawbacks. Both clients and servers run a portion of the application logic, with the servers handling the loads of back-end data management. This requires that client software be installed, managed, and updated on a potentially large number of systems. The two-tier model tends to move large numbers of records across the network to clients that may not always be optimized to handle them. The model is not efficient in distributed wide area network environments like the Internet. For example, a Web client may be a hand-held system with limited memory and processing power. It cannot be relied on to handle front-end processing tasks.

QL became popular as a form of client/server middleware because it was efficient at selecting and moving just the records that were needed. In addition, it could run stored procedures directly at the database server, rather than moving data to the client and then running procedures on the client. The three-tiered model extends this approach by moving application logic (the equivalent of SQL stored procedures) to a middle server called the application server. This server performs processing for the client and other tasks as necessary.

Presentation services tier Responsible for gathering information from the user, sending the user information to the business services for processing, receiving the results of the business services processing, and presenting those results to the user.

Business services tier Responsible for receiving input from the presentation tier, interacting with the data services to perform the business operations that the application was designed to automate (for example, income tax preparation, order processing, and so on), and sending the processed results to the presentation tier.

Data services tier Responsible for storage, retrieval, maintenance, and integrity of data.

The Web is a good example of where to apply the three-tier model. Application developers know little about the potential clients except that they have a near-universal interface: the Web browser. The middle tier accepts requests from clients, retrieves information from the back-end systems, processes the data, and forwards the results to the client. The client is relieved of a lot of work. Thin clients are a good fit in this model.

The middle tier may provide the following services:

The code for the middle tier can exist on multiple application servers, all accepting requests from multiple users (via load-balancing switches) and all connecting with the back-end systems.

Message queuing allows clients to interact asynchronously with the back-end servers. In other words, transactions don't need to follow a precisely timed flow. The client may need to wait for a message from the server.

The middle-tier server can provide transaction monitoring, which tracks the order and events of an online exchange to ensure that everything is complete and handled correctly. If not, the transaction is backed out.

Distributed object computing services in which application logic and/or data resides in objects that are made available through an ORB (object request broker). An ORB provides a sort of software bus through which objects on one system can make requests of objects on another system. See "Distributed Object Computing."

The thin client model represents another aspect of multitier architectures. A thin client is a Web browser device that relies on an external server to run its applications and store its data. It displays information and accepts keyboard inputs. Some systems have small drives to cache objects from Web sites. A typical thin client is the inexpensive Internet appliance you've seen pictured on kitchen counters with TV-like knobs for accessing the interface. Users store data on a server located at a service provider or an online service. Electronic mail is accessed through a Web browser interface on a remote e-mail server. In this model, the service provider is the middle tier. In fact, giant Internet data centers are emerging to support this model. In some cases, the data center caches so much information via content distribution techniques that users are likely to find what they need at the data center rather than out on the bigger Internet. The Internet data center could be referred to as "Internet in a building."

Tags: architecture exam mult tier

Posted by: mikeem

Multi-tier Architecture: Know-how

Tue, 18 Dec 2007 21:34:42 -0000

Highlights and Sticky Notes:

High-level Analysis of the Architecture

emerged in the 1990s to overcome the limitations of the two-tier architecture the third tier (middle tier server) is between the user interface (client) and the data management (server) components. This middle tier provides process management where business logic and rules are executed and can accommodate hundreds of users (as compared to only 100 users with the two tier architecture) by providing functions such as queuing, application execution, and database staging.

The three tier architecture is used when an effective distributed client/server design is needed that provides (when compared to the two tier) increased performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user.

1.1.1 3-Tier Architecture

The 3-tier architecture overcomes the weaknesses of the 2-tier and client/server architectures. It contains a client workstation, a component server, and a database server. The user interface is on the client side while business logic and data management are in dedicated tiers. Business logic resides on one machine where it can be easily managed. Successful implementation of a 3-tier architecture requires considerable applied

Tags: architecture exam multi tier

Posted by: mikeem

Interpreted Language

Tue, 18 Dec 2007 21:25:31 -0000

Highlights and Sticky Notes:

The term "InterpretedLanguage" is archaic, and referred to a language that was evaluated as the programmer typed it instead of being compiled into a single monolithic "executable". Some early languages (Pascal and many early implementations of Basic, for example) could be either compiled or interpreted according to the desire of the programmer and system administrator. While the term is still used informally in some circles, most professionals agree that advances in both compiler and interpreter design and implementation have made the distinction moot in any rigorous sense.

Tags: compiled exam interpreted

Posted by: mikeem