Winter 2011

Master of Computer Application (MCA) Semester 3 MC0071 Software Engineering 4 Credits

(Book ID: B0808 & B0809) Assignment Set 1

Book ID: B0808 1. Explain the following development models: a. Serial or Linear Sequential b. Incremental Solution:

A. The Serial or Linear Sequential Development Model

This Model also called as the Classic life cycle or the Waterfall model. The Linear sequential model suggests a systematic sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. Below Figure shows the linear sequential model for software engineering Modeled after a conventional engineering cycle, the linear sequential model has the following activities:

The linear sequential model

System/Information Engineering and modeling: Because software is a part of a large system, work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interact with other element such as hardware, people and databases. System engineering and analysis encompasses requirements gathering at the system level with a small amount of top level design and analysis. Information engineering encompasses requirements gathering at the strategic business level and at the business area level. Software requirement analysis The requirement gathering process is intensified and focused specifically on software. To understand the nature of the program to be built, the software engineer (analyst) must understand the information domain for the software, as well as required function, behavior, performance and interface. Requirements for the both system and the software are documented and reviewed with the customer.

Design Software design is actually a multistep process that focuses on four distinct attributes of a program, data structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process translates requirements into a representation of the software that can be assessed for quality before coding begins. Like requirements, the design is documented and becomes part of the software configuration. Code Generation The design must be translated into a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanistically. Testing Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results.

Support Software will undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adopted to accommodate changes in its

external environments or because the customer requires functional or performance enhancements. Software maintenance re-applies each of the preceding phases to an existing program rather than a new one. A successful software product is one that satisfies all the objectives of the development project. These objectives include satisfying the requirements and performing the development within time and cost constraints. Generally, for any reasonable size projects, all the phases listed in the model must be performed explicitly and formally. The second reason is the one that is now under debate. For many projects the linear ordering of these phases is clearly the optimum way to organize these activities. However some argue that for many projects this ordering of activity is unfeasible or suboptimal. Still waterfall model is conceptually the simplest process model for software development that has been used most often. Limitation of the linear sequential model 1. The linear sequential model or waterfall model assumes the requirement of a system which can be frozen (baseline) before the design begins. This is possible for systems designed to automate an existing manual system. But for a new system, determining the requirements is difficult as the user does not even know the requirements. Hence, having unchanging requirements is unrealistic for such projects. 2. Freezing the requirements usually requires choosing the hardware (because it forms a part of the requirement specifications) A large project might take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing , it is likely the final

software will use a hardware technology on the verge of becoming obsolete. This is clearly not desirable for such expensive software systems. 3. The waterfall model stipulates that the requirements be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely and then later enhance the system in phases. This is often done for software products that are developed not necessarily for a client, but for general marketing, in which case the requirements are likely to be determined largely by the developers themselves. 4. It is a document driven process that requires formal documents at the end of each phase. This approach tends to make the process documentation-heavy and is not suitable for many applications, particularly interactive application, where developing elaborate documentation of the user interfaces is not feasible. Also, if the development is done using fourth generation language or modern development tools, developing elaborate specifications before implementation is sometimes unnecessary. Despite these limitations, the serial model is the most widely used process model. It is well suited for routine types of projects where the requirements are well understood. That is if the developing organization is quite familiar with the problem domain and requirements for the software are quite clear, the waterfall model or serial model works well.

B. The incremental Development Model

The incremental model combines elements of the linear sequential model with the iterative of prototyping. Below Figure shows the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable increment of the software. For e.g., word processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment could incorporate the prototyping paradigm

The incremental model

When an incremental model is used, the first increment is a core product. That is, basic requirements are addressed, but many supplementary features remain undelivered. The customer uses the core product. As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the

delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model is iterative in nature. The incremental model focuses on the delivery of an operational product with each increment. Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff can be added to implement the next increment. In addition increments can be planned to manage technical risks. For e.g.: a major system might require the availability of new hardware i.e., under development and whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end users- without inordinate delay.

2. Describe the Object Interface Design.

Solution: Object interface design is concerned with specifying the detail of the object interfaces. This means defining the types of the object attributes and the signatures and the semantics of the objects operation. If an objects oriented programming language is being used for implementation, it is natural to use it to express the interface design.