Write a letter to your uncle describing to him the first impression of your college.

Education Hall

City A.B.C.

July 27,2015

My dear Uncle,

                         I'm happy and gay like a winter sunny day and I hope this letter will find you in the best of your health. You will be glad to know that I have got admission to the first year class in Government College of Science, Faisalabad. My college is one of the renowned institution of the Punjab. I'm greatly impressed by the lovely building, the vast playground and the charming greenery of the college. Students come here from all over the Punjab.

                         First day when I was entered the college, some senior students welcomed me and guided me in every matter.The staff of the college is highly qualified. The professors are kind, polite co-operative and punctual. They are well-dressed and well-mannered. They guide the students in academic and sports activities regularly.

                          College life is quite different from that of school. It is interesting and thrilling. Discipline here is not strict as it was in school. Students enjoy full freedom and actively participate in co-curricular activities of the college. They are considered mature to act upon the college rules. There is a big library and fresh magazines and news papers both in english and urdu are available in it. There is a college canteen as well.. Me class fellows are very brilliant and hard working. I'm enjoying myself very much in this great institution. I hope to show an excellent performance in this college. I shall write to you in detail very soon.

                           Please pay my compliments to dear aunt and love to youngers.

Yours affectionately,

X.Y.Z.

Read More

Process Models (Part 2 )

Process Assessment and Improvement

The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s need, or that it will exhibit the technical characteristics that will lead to long term quality characteristics. Process patterns must be coupled with solid software engineering practice. Assessment attempts to understand the current state of the software process with the intent of improving it. A number of different approaches to software process assessment and improvement have been proposed over the past few decades:

·         Standard CMMI Assessment Method for process Improvement SCAMPI

·         CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

·         SPICE (ISO/IEC15504)

·         ISO 9001-2000 for software

Perspective Process Model

Prescriptive process models define a prescribed set of process elements and a predictable process work flow. Each process model prescribes a set of process elements – framework activities, software engineering action, tasks, work products, quality assurance and change control mechanisms for each product. Each process model also prescribes a process flow that is manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activities but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity in a different manner.

Waterfall Model

There are times when the requirements for a problem are well understood, when work flows communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well defined adaptation or enhancement to an existing system must be made (e.g., an adaptation to accounting software that has been mandated because of changes to government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable. The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begin with customer specification of requirements and progresses through planning, modeling, construction and deployment, culminating in ongoing support of the completed software.

Problems with Waterfall Model

Real projects rarely follow the sequential flow that the model proposes. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. The customer must have patience. A working version of the program will not be available until late in the project time span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

The V Model

A variation in the representation of the waterfall model is called the V model. As a software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution. One code has been generated, the team moves up the right side of the V, essentially performing a series of tests that  validate each of the models created as the team moved down the left side. In reality, there is no fundamental difference between the classic life cycle and the V-model.

Incremental Process Models

The incremental model delivers a series of release, called increments, that provide progressively more functionality for the customer as each increment is delivered. The incremental model combines elements of linear and parallel process flows. When an incremental model is used, the first increment is often a core product. The basic requirements are addressed but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer or undergoes detailed evaluation. As a result of use and/or evaluation, a plan is developed for the next increment. This process is repeated following the delivery of each increment, until the complete product is produced.

Evolutionary Process Models

Software like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds making a straight line path to an end product unrealistic. Evolutionary models iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software. Prototyping, The spiral model.

Prototyping

Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human machine interaction should take. In such similar cases we use prototyping paradigm. Although prototyping can be used as a stand alone process model, it is more commonly used as a technique that can be implemented within the context of any other process model. The prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy. Prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part) and the actual software is engineered with an eye toward quality.

The Spiral Model

The spiral model is evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. Using the spiral model, software is developed in a series of evolutionary release. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. The spiral model is realistic approach to the development of large scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but more important enables you to apply the prototyping approach at any stage in the evolution of the product.

Read More

The Unified Process

The Unified Process

There is a need of use case driven architecture centric, iterative and incremental software development (Unified Process). In some ways the unified process is an attempt to draw on the best features and characteristics of traditional software process models, but characterize them in way that implements many of the best principles of agile software development. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development. It focuses on the customer communication and software architecture. Unified Modeling Language is a robust notation for the modeling and development of object oriented system. UML did not provide the process framework to guide project teams in their application of the technology. UP is the framework for object oriented software engineering using UML. The five UP phases do not occur in sequence, but rather with staggered concurrency.

Phases of Unified Process

The Inception Phase:

Customer communication and planning activity. Business Requirements for the software are identified by collaborating with stakeholders. A rough architecture for the system containing fundamental features and functions is proposed. Fundamental business requirements are describes though a set of preliminary use cases. Planning identifies resources, assesses major risks defines a schedule, and establishes a basis for the phases that are to be applied as the software increment is developed.

The Elaboration Phase:

It encompasses the communication and modeling activities of the generic process model. It refines and elaborates the preliminary use cases define in the inception phase. It refines architectural representation to include five different views of the software. ( The use case model, The requirements model, The design model, The implementation model, The deployment model.). The architecture still don’t provide all features and functions required to use the system. The plan is carefully reviewed at the culmination of the elaboration phase to ensure that scope, risks, and delivery dates remain reasonable. Plan can be modified, if needed.

The Construction Phase:

It encompasses of construction activity. Requirements and design models are completed to reflect the final version of the software increment. Using the architectural model as input, the construction phase develops software components that will make each use case operational for end users. As components are being implemented, unit tests are designed and executed for each component. Integration of components are conducted.

The Transition Phase:

The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment activity. Software is given to end users for beta testing and user feedback. Defects and necessary changes are noted by user feedback. The software team creates the necessary support information that is required for the release.( User manuals, trouble shooting guides, installation procedures). A usable software is delivered.

The Production Phase:

During this phase, the ongoing use of the software is monitored. Support for the operating environment (infrastructure) is provided. Defect reports and requests for changes are submitted and evaluated. This phase coincides with the deployment activity. It is likely at the same time the construction, transition, and production phases are being conducted.

Personal and Team Process Model

The best software process is one that is close to the people who will be doing the work. Personal software process and team software process.

Personal Software Process (PSP)

The personal Software process emphasizes personal measurements of both the work product that is produced and the resultant quality of the work product. Practitioner is responsible for project planning and to control the quality of all software work products that are developed. The PSP model defines five framework activities.

Planning: Sources estimates, a defect estimate, metrics are recorded on templates, development tasks are identified and a project schedule is created.

High-Level Design: External specifications for each component is developed, a component design is created, prototypes are built if needed, uncertainty recorded and tracked.

High-Level design review: Formal verification are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.

Development: The component-level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.

Postmortem: Using the measures and metrics collected the effectiveness of the process is determined by applying statistical analysis.

PSP represents a disciplined, metrics-based approach to software engineering.

Team Software Process (TSP)

The goal of TSP is to build a self directed project team that organizes itself to produce high quality software. TSP recognizes that the best software teams are self directed. Team members set project objectives adapt the process to meet their needs. The teams control the project schedule and through measurement and analysis of the metrics collected, work continually to improve the team’s approach to software engineering. TSP defines these framework activities project launches, high level design, implementation, integration and test and postmortem (same like PSP).

Read More

Process Models

What is process Model?

When you work to build a product or system, it’s important to go through a series of predictable steps, a road map that helps you create a timely, high-quality result. The road map that you follow is called a “software process”. A process can be defined as a collection of work activities, actions and tasks that are performed when some work product is to be created. Each of these activities, actions and tasks reside within a framework on model that defines their relationship with the process and with one another.

Generic Process Model

Each framework activity as populated by a set of software engineering actions. Each software  engineering action is defined by a set of task set that identifies the work tasks that are to be completed, the quality assurance points that will be required, and the milestones that will be used to indicate progress.

Process Flow

It describes the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time.

·         Linear Process Flow

·         Iterative Process Flow

·         Evolutionary Process Flow

·         Parallel Process Flow

Linear Process Flow

A linear process flow executes each of the five framework activities in sequence, beginning with communication and culmination with deployment.

Iterative Process Flow

An iterative process flow repeats one or more of the activities before proceeding to the next.

Evolutionary Process:

An evolutionary process flow executes the activities in a circular manner. Each circuit through the five activities leads to a more complete version of the software.

Parallel Process Flow

A parallel process flow executes one or more activities in parallel with other activities. For example, modeling for one aspect of the software might be executes in parallel with construction of another aspect of the software.

 

Defining a framework activity

More information is required to start each activity. A software team should know,”what actions are appropriate for framework activity given the nature of the problem to be solved the characteristics of the people doing the work, and the stakeholders who are sponsoring the project?”

For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call with the appropriate stakeholder. If the project was considerably more complex with many stakeholders, each with a different set of (sometime conflict) requirements, the communication activity might have more detailed actions.

Identifying a task set

Each software engineering action can be represented by a number of different task set. A task set defines the actual work to be done to accomplish the objectives of a software engineering action. You should choose a task set that best accommodates the needs of the project and characteristics of your team.

Process Pattern

Every software team encounters problems as it moves through the software process. A process describes a process related problem that is encountered during software engineering work, identifies the environment in which the problem has been encountered and suggests one or more proven solution to the problem. ( A template consisting of method describing problem solution.) A pattern might be used to describe a problem (and solution) associated with ( a complete process model, a framework activity , or an action within a framework activity)

Pattern Template

A pattern template provides a consistent means for describing a pattern.

 Pattern Name: The pattern is given a meaningful name describing it within the context of the software process ( e.g. Technical Review )

Forces: The environment in which the pattern is encountered and the issues that make the problem visible and may affect its solution.

Type: The pattern is specified.

Stage Pattern: defines a problem associated with a framework activity for the process. Since the framework activity encompasses multiple actions and work tasks , a stage pattern incorporates multiple tasks patterns that are relevant to the stage. An example of a stage pattern might be Establishing Communication Gathering and other.

Task Pattern: Defines a problem associated with a software engineering or work task and relevant to successful software engineering practice (e.g. Requirements gathering is a task pattern.)

Phase Pattern: Defines the sequence of framework activities that occur within the process, even when the overall flow of activities is iterative in nature. An example of a phase pattern might be Spiral Model or prototyping. 

Read More