Learn Software Development » Model

Modeling Practices – Type of Software Engineering Practice

ashish — Tue, 20 Oct 2009 17:18:31 +0000

We create models to gain a better understanding of the actual entity to be built. If the entity is a physical thing, we can build a model that is identical in form and shape but smaller in scale. However, when the entity is a software, a model is created that is capable of representing the information that software transforms, the architecture and functions that enable the transformation to occur, the features that the users desires, and the behavior of the system as the transformation is taking place.
Two classes of models are created :
1. Analysis models : they represent the customer requirements by depicting the software in three different domains : the information domain, the functional domain, and the behavioral domain. All analysis methods are related by a set of operational principles :
- The information domain of a problem must be represented and understood.
- The function that the software performs must be defined.
- The behavior of the software must be represented.
- The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion.
- The analysis task should move from essential information toward implementation detail.
2. Design Models : These models represent characteristics of the software that help practitioners to construct it effectively : the architecture, the user interface, and the component-level detail. There is no shortage of methods for deriving the various elements of a software design. A set of design principles that can be applied regardless of the method that is used.
- Design should be traceable to the analysis model.
- Always consider the architecture of the system to be built.
- Design of data is as important as design of processing functions.
- Interfaces (both internal and external) must be designed with care.
- User interface design should be tuned to the needs of the end-user.
- Component-level design should be functionally independent.
- Components should be loosely coupled to one another and to the external environment.
- Design representations should be easily understandable.
- The design should be developed iteratively.

Capability Maturity Model Integration (CMMI)

ashish — Sat, 10 Oct 2009 09:03:16 +0000

Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. It helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

CMMI currently addresses three areas of interest:
(1) Product and service development — CMMI for Development (CMMI-DEV),
(2) Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
(3) Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI MODELS
CMMI best practices are published in documents called models, each of which addresses a different area of interest.
- CMMI for Development (CMMI-DEV), v1.2 was released in August 2006. It addresses product and service development processes.
- CMMI for Acquisition (CMMI-ACQ), v1.2 was released in November 2007. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
- CMMI for Services (CMMI-SVC), v1.2 was released in February 2009. It addresses guidance for delivering services within an organization and to external customers.
- CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is expected to be released in 2010. CMMI Version 1.3—Plans for the Next Version.
Regardless of which model an organization chooses, CMMI best practices should be adapted by an organization according to its business objectives.

The benefits you can expect from using CMMI include the following:
- Your organization’s activities are explicitly linked to your business objectives.
- Your visibility into the organization’s activities is increased to help you ensure that your product or service meets the customer’s expectations.
- You learn from new areas of best practice (e.g., measurement, risk).

CMMI APPRAISAL
An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons:
- To determine how well the organization’s processes compare to CMMI best practices, and to identify areas where improvement can be made.
- To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices.
- To meet the contractual requirements of one or more customers.

Database System Concepts – Data Model, Schemas and Database state

ashish — Tue, 04 Aug 2009 03:05:29 +0000

A data model is a collection of concepts that can be used to describe the structure of a database. By structure of the database we mean the data types, relationships, and constraints that should hold on the data. Most data models also include a set of basic operations for specifying retrievals and updates on database.

Categories of Data Models:
- High level or Conceptual data models : These models provide concepts that are close to the way many users perceive data. They use concepts such as entities, attributes, and relationships. An entity represents a real-world object or concept such as an employee or a project. An attribute represents property of interest that describes an entity such as employee’s salary or name. A relationship represents an interaction among the entities.
- Representational data models : These models provides concept that may be understood by end users but that are not too far removed from the way data is organized within the computer. They are used most frequently in traditional commercial DBMSs and they include the widely used relational model as well as the network and hierarchical models. These models represent data by using record structures and hence are sometimes called record-based data models.
- Low level or Physical data models : These models provide concepts that describe the details of how the data is stored in the computer by representing information such as record formats, record orderings, and access paths. An access path is a structure that makes the search for particular database records efficient.

Schemas:
The description of a database in any data model is called the database schema which is specified during the database design and is not expected to change frequently. A displayed is called a schema diagram.

A schema diagram displays only some aspects of a schema, such as names of record types and data items, and some types of constraints.

Database State or Iinstance: The actual data in a database changes every time data is inserted, deleted, or modified. The data in the database at a particular moment in time is called a database state or a snapshot. It is also called the current set of occurrences or instances in the database.

Distinguish between Database State and Database Schema:
When a new database is defined, we specify its database schema only to the DBMS. At this point, the corresponding database state is empty state. The initial state of the database is got when the database is first populated or loaded with the initial data. From then on, every time an update operation is applied to the database, we get another database state.

Effort estimation techniques

ashish — Sun, 10 Aug 2008 18:38:50 +0000

A new project is being thought of (or even an extension of the current product). As an example, say you want to build a new shopping cart application for your website. In order to get started, besides knowing exactly what you want to build (the product details), you also need to start estimating how many people you will need and how long it will take. And this process of estimation is probably one of the more difficult parts of software development, something that can make or break a project. Suppose your estimation goes wrong, and you estimate too little effort for the project. In such a case, you will be forced to make compromises / overwork the people involved / deliver a low quality work. All of these are major factors that could cause the project to fail. Fortunately, there are a number of different effort estimation techniques that could be employed (this post just has brief descriptions, details for each of these will be covered in future posts):

# Function Point Analysis (FPA): A way to break down the work into units to express the amount of business function an information system provides to a user
# Parametric Estimating / Estimation Theory: Estimating the value based on measured / empirical data
# Wideband Delphi: A estimation theory that works on the basis of developing a consensus for the estimation (typically based on a series of group meetings)
# Cocomo: An algorithmic estimation model, using a regression formula derived from historical data and current project details
# Putnam Model: Taking data from the project (such as effort and size and fitting these data to a curve). This is an empirical model.
# SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk.: System Evaluation and Estimation of Resources – Software Estimating Model. This model is based on a mixture of statistics and algorithms
# Proxy-based estimating (PROBE) (from the Personal Software Process): Proxy based estimating produces size estimates based on previous developments in similar application domains
# The Planning Game (from Extreme Programming): This is the process that depends on release planning and iteration planning (inside iteration planning, requirements are broken down into tasks and tasks are estimated by the programmers)
# Program Evaluation and Review Technique (PERT): PERT is intended for very large-scale, one-time, complex, non-routine projects, and has a great advantage of being able to incorporate uncertainty
# Analysis Effort method: This method is best suited to producing initial estimates for the length of a job based on a known time duration for preparing a specification
# TruePlanning Software Model: Parametric model that estimates the scope, cost, effort and schedule for software projects
# Work Breakdown Structure: In this technique, all the individual tasks are laid out with their estimates and description, and they can be summed to display the total effort

An example of unrealistic expectations in the service industry

ashish — Tue, 29 Jul 2008 17:46:34 +0000

This is a true example from around 6 years back when I was working for an IT software solutions provider (the firm did software projects for different customers). This was a decent sized company that had something like 12000 people on the rolls, doing everything from development to testing to requirements analysis, and so on. I was more into the area of a business analyst, translating the requirements document into a form that the developers working on the project would understand.
This was a new project with a new medium sized bank in the Midwest, and the hope was that we would be able to do this project well enough and give them a system that would work so well for them that they would continue with the company and be the start of a long and serious (and profitable) relationship. Sounds good, right ? Well, read on.
Around this time, our company, that was a publicly listed company was getting on just like the other service companies of that time, doing okay, but not generating great figures. Management was getting hit by analysts, and passed on a directive that every project needs to meet the company defined margin. Exceptions only when pleaded before the executive committee, and not otherwise. Implicit was the expectation that anybody who does a project that does not promise enough margin would need to explain the project.
Now, since our project was with a new customer with whom we had high hopes for the future, we could not charge our expected rates; after all, why would the customer then select us ? So, our account manager along with the Vice-President of the unit went ahead and quoted a rate that was atleast 20% lower (getting fewer people assigned to the project than necessary). Guess what ? Pretty soon, the strains and missing people started to show.
Ego also plays a part. For a Vice-President to go before the committee and plead for more money (a reduction in margin) would reflect adversely. The members of the committee, who might be expected to provide an experience of being able to handle these kind of situations and offer some latitude did not do so since they were never offered this project for review. Pretty soon, somebody senior in the team had the bright idea that weekends could be converted into work hours (maybe 1 weekend in 3 could be off), and this idea was implemented with gusto.
You can guess the rest. People from outside the project did not want to join, quality reviews of the project were hesitant because of the many exceptions, and eventually the customer could make out that the quality was not as desired. Project over, account over, and pretty soon the project manager and other senior team members quit and went to other companies.
This was a disaster caused by the management reacting adversely to poor numbers, and unwilling to exercise the due diligence in doing a project (after all, the first criteria for a project should be to make it successful).

How many of you have similar experiences ?