Posts

Showing posts from January, 2011

Types of Requirements

Customer Requirements Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing: Operational distribution or deployment : Where will the system be used? Mission profile or scenario : How will the system accomplish its mission objective? Performance and related parameters : What are the critical system parameters to accomplish the mission? Utilization environments : How are the various system components to be used? Effectiveness requirements : How effective or efficient must the system be in performing its mission? Operational life cycle : How long will the system be in use by the

Requirement Engineering

Quality of product Without well written document -- Developers do not know what to build -- Customers do not know what to expect -- What to validate Requirements describe What not How Produces one large document written in natural language contains a description of what the system will do without describing how it will do it. Process that creates it Requirement Engineering Requirement Engineering is the disciplined application of proven principles, methods, tools, and notations to describe a proposed system’s intended behavior and its associated constraints. SRS may act as a contract between developer and customer. State of practice Requirements are difficult to uncover • Requirements change • Over reliance on CASE Tools • Tight project Schedule • Communication barriers • Market driven software development • Lack of resources Example A University wish to develop a software system for the student result management of its M.Tech. Programme. A problem statement is to be prepared for the s

Fountain Model

• Support Incremental Development • Recognizes that some activities can’t stand before others, yet there’s a considerable overlap of activities throughout the development cycle • Implies that you do some analysis, then some design, then some implementation • Parallelism among various phases and iteration within phases • Development of an object-oriented system that more likely to lead us to focus on sections of the whole known as clusters or subsystems • Subsystems are collections of classes which work closely together • Supports human learning and is recommended for most projects SDLC is a systems approach to problem solving and is made up of several phases. A developer may or may not use or apply SDLC, but based on my experience, it is highly advantageous to use one. We did a system before where we didn’t plan much how we will execute, start and finish building a system. The result was a complete catastrophe! We suffered “groping in the dark” syndrome, regretted ever wo

Synchronize and Stabilize Model

• Type of Incremental Model • Allows many teams to work efficiently in parallel • A nightly compilation of builds of the entire project is made to piece together all current components • An alpha release was done for internal testing, a couple of beta releases took care of a wider testing range outside the company. Finally, a release candidate leading to the final version, called a gold master, was released to manufacturing • At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs • There is heavy emphasis in schedule management and perfection

Incremental Model

• Divides the product into builds, where sections of the project are created and tested separately • Each build contains an operational quality subsystem • Each additional build, a new subsystem is integrated with the previous build • You will notice that this model is very much like the Spiral Model except that instead of prototype, they’d rather call it builds. These builds, like prototypes, are tested separately first. Each build has a subsystem in Incremental Method, whereas in Spiral, subsystems may or may not be used • Likely to find errors in user requirements quickly

Rapid Prototyping Model

• Emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness • Develop a system with reduced capability • Present to client for approval • Once the prototype is approved, it is discarded and the “real” software is written. • Develops specification with better understanding • Exactly like the Spiral Model, where a prototype or only “shadow” of the real software is made, where the system (during implementation stage) is not that graphically perfect but features are functioning well for testing purposes • Only difference is, in Rapid Prototyping, it requires client approval prior to the building of the “real” software

Build and Fix Model

• Crudest of the models • Implementation of system without specification nor design • May work for small scale projects • Code is written, then modified until client is happy • VERY RISKY! • I know of a developer who does just this kind of work strategy. He was given an assignment, but instead of planning properly, he will just code it immediately without specification or design. He improves it until his client is happy. If the client is dissatisfied, he doesn’t give a damn about it.

Spiral Model

• Most generic of the models. Most life cycle models can be derived as special cases of the spiral model • Set of important requirements are selected for each prototype. Thus, developers can split the requirements and work first on those with high priority • Employs a risk management approach to software development especially in the stages of Specification, Design, Implementation and Integration • Emphasizes the need to reiterate earlier stages a number of time as the project progresses • Actually a series of short waterfall cycles, each producing an early prototype, representing a part of the entire project. It’s like using the waterfall model as guide in doing one prototype only. • If one prototype is finished (except perhaps the polishing of graphics), a developer can proceed to the next prototype. Build, test and integrate to the first prototype • Helps demonstrate a proof of concept early in the cycle • Incorporates prototyping and software quality objectives • Giv

Waterfall Model

• One of the older SDLC models • Each single step in the process of system development is first written down in the form of specifications and reports. Only then are the actual phases initiated in practice • The execution of a project appears as a sequence of stages in which the output of each stage becomes the input for the next • The stages in Waterfall method are divided into the ff: 1. Project planning / feasibility study – commonly known as Requirements Stage. It is in this stage that developers/stakeholders determine the project goal 2. System analysis – refines project goals into defined functions and operations. It also analyses end-user information needs (Specification stage) 3. System design – describes desired features and operations in detail (Design stage) 4. Implementation / Coding (Implementation stage) 5. Integration and testing – brings all the individual system components into one, then testing it for errors, bugs, etc. (Integration stage) 6. Acceptan

Various SDLC models

1. Waterfall Model 2. Spiral Model 3. Build and Fix Model 4. Rapid Prototyping Model 5. Incremental Model 6. Synchronize and Stabilize Model 7. Fountain Model

Software Development life Cycle

The Systems Development Life Cycle (SDLC) , or Software Development Life Cycle in systems engineering , information systems and software engineering , is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems . In software engineering the SDLC concept underpins many kinds of software development methodologies . These methodologies form the framework for planning and controlling the creation of an information system [ 1 ] : the software development process .

Y2K Problem

It was simply the ignorance about the adequacy or otherwise of using only last two digits of the year. The 4-digit date format, like 1964, was shortened to 2-digit format, like 64. The Year 2000 problem (also known as the Y2K problem , the millennium bug , the Y2K bug , or simply Y2K ) was a problem for both digital (computer-related) and non-digital documentation and data storage situations which resulted from the practice of abbreviating a four-digit year to two digits. In computer programs, the practice of representing the year with two digits becomes problematic with logical error(s) arising upon "rollover" from x99 to x00. This has caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000 and on other critical dates which were billed " event horizons ". Without corrective action, it was suggested that long-working systems would break down when the "...97, 98, 99, 00..." ascending numbering

How to develop healthy softwares

It is not difficult to develop a software , but it is very difficult to develop a good and health software. To develop a healthy and good software which meets the customer demand is only develop with the help of software engineering As per the IBM report, “31%of the project get cancelled before they are completed, 53% overrun their cost estimates by an average of 189% and for every 100 projects, there are 94 restarts Why software engineering Change in nature & complexity of software Ready for change Concept of one “guru” is over We all want improvement Some software failure It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business. Ariane 5 The rocket was destroyed after 39 seconds of its launch, at an altitude of two and a half miles along with its payload of four expensive an

Way to compete with others

We are living in the world of competetion.To compet with others we must be fast and uptodate. The one of the best way to survive in this competetive world is to link your business with computer ie automate your business , buy softwares to perform your task easily , earlier with less cost. Computer software, or just software, is a collection of computer programs and related data that provide the instructions to a computer what to do and how to do it. Software refers to one or more computer programs and data held in the storage of the computer for some purposes. Program software performs the function of the program it implements, either by directly providing instructions to the computer hardware or by serving as input to another piece of software. The term was coined to contrast to the old term hardware (meaning physical devices). In contrast to hardware, software is intangible, meaning it "cannot be touched".Software is also sometimes used in a more narrow sense, meaning appl