Software Development Life Cycle Models - Essay Example

Design of RDBMS Application Case Study Task Software Development Life Cycle Models and Design Techniques 0 Introduction A Standish Group research1 shows that not more than 9% of the software projects succeed in large companies. Even out of this 9% projects, they hardly meet 42% of the originally planned requirements. This astonishing revelation tells us that most of the software projects are either ill managed or have not been understood properly. Owing to its importance, software life cycle models have always been of great interest to people who wanted to deliver software out of a production line. There are a number of SDLC Models that have been under the lens. Starting from the Waterfall model to the various strains of the object oriented models, everyone of them define their approaches. Let us take a look at the contemporary models being used by the software industry. 2.0 Water Fall Model This is the first derivative of the classic Software Development Life Cycle model which goes through the processes of requirement capturing and analysis, System Analysis and Design, Code Generation, testing and maintenance. Water fall model (Royce,1970) differs from the sequential software development life cycle in inserting iteration at the end of every phase to reduce large iterations over several phases which could turn out to be costly exercises. It also provides for a validation at the end of every phase output, defining the deliverables at the end of every phase. In this process, incremental development was introduced for both requirement capturing and for development, along with a clear validation at the end of every phase made this process more successful than the sequential SDLC. Software projects more controllable. 3.0 Prototyping Model This model, though under use in various unofficial forms across the developing community, became a standard process in 1991. (Pomberger,1991). The phased model that was introduced in the waterfall model was seen more as an iterative possibility. At the end of every phase, a prototype was made and shown to the customer. At the end of the study, a prototype is produced for the user interfaces and shown to the user to get his feedback. Subsequently, at every phase similar methodology is adopted to bring in prototypes at the end of every phase. During this methodology, experiments are conducted on the prototype at every iteration to check the effectiveness of the prototype for various functionalities expected out of the system. This way when the customer receives the software, he is very satisfied. 4.0 Object Oriented Life Cycle Model In this model, we do not train our eyes on the functionalities of the software needed, rather on the objects that we have and we can construct. After the requirement analysis, which is very similar to the other models discussed earlier, the objects are identified and development is taken up for those objects that need to be done fresh. Others that could be inherited, are taken from the earlier objects already existing. Advantages of this life cycle is that, since it inherits and reuses many of the objects already existing, the development cycle time should be coming down. By the same measure, it should also bring down the time to test, the time to maintain and the time to make changes in the software. Primarily, this model postulates reusability of objects and classes within programs / projects and across programs / projects2. Clubbing with the prototyping model, most of the common object models use prototyping of individual classes / objects with their performances resulting in easy spotting of errors and inconsistencies early on. Error fixing and modifications are much more easily understood and presented under such conditions resulting in easier fixes. 5.0 Design Techniques Derr (1995) is the first major proponent of the object model that follows the following steps to reach design solutions: 1. A Problem Statement 2. Identify object classes and their attributes 3. Discard unnecessary classes and attributes 4. Inherit attributes The first step is to identify the problem. The problem statement is made based on the identified problem. All the classes that lead to the problem are then identified. Whereas verbs reflect the functional methods, functions, etc., the nouns in the problem statement reflect the objects or classes. (Abbott, 1983). The nouns in the problem statement are picked up listed as the objects in a table. The next step is to find out the inheritance or relationship between the objects and design the objects accordingly3. This methodology could be adopted to design either a two-tier or a three-tier application over an intranet or an internet. 6.0 Bibliography 1. Standish Group International, The CHAOS Report (1995), available at the following site: http://www.standishgroup.com/sample_research/chaos_1994_1.php 2. Nguyen Xuan Huy, Software Engineering, National center for Science and Technology, available at http://www.netnam.vn/unescocourse/se/software.htm 3. 1998, Developing a Database Connectivity for Intranet/Internet Applications, available at http://www.esatclear.ie/chumor/Chapter4.htm Task 1-2 Entity, entity set, attributes, relationships (mandatory & optional) An Entity is an object. It can also be visualized as a noun. Example: human, table, chair are all entities. Every entity is characterized by its attributes. For instance, a human can be a Male or a Female; will have an age; a name. All these attributes that characterize the entity called human. Similarly, most of the entities are uniquely identifiable. Such an attribute that uniquely identifies an entity becomes a primary key. In case of an RDBMS, these entities are also called a table. A collection of entities become an entity set. One human is an entity. A collection of humans become an entity set. Between the entity and its attributes, there are always definable relationships. Two entities could be related. Some of these relationships could be optional or mandatory. Primary Key, foreign key, composite key Primary key is the unique characterization of an entity. Any key which is not a unique key is referred to as an alternate key. Such an alternate key when it becomes the primary key of another entity so that a relationship can be established, then that key is called a foreign key. Some times for the sake of accessing specific data, we use more than one attribute to represent a key. Such attributes may be concatenated or might be part of a formula, to make up a composite key. Data dictionary Data dictionary is the set of all entities, their attributes and relationships. All these together form the data dictionary. Therefore, you can also look at this as the complete collection of all metadata in a database. Connectivity and Cardinality Connectivity refers to the type of relationship that exists between entities. This can be one to one, one to many, many to one or many to many. Whereas, cardinality refers to the lower and upper limits of a relationship. Data integrity, entity integrity and referential integrity Data integrity is maintaining consistency of data across the entire database and/or entity. Data integrity loss could happen when part of entity attributes are updated for a new value and the rest are not. Typical example could be, when an entity employee is being updated and when the data pertaining to the name, number are updated and before updating the other attributes if, say, the power fails or due to whatever reason if part of the data is not updated then that becomes a data integrity issue. A referential integrity happens when one entity refers another entity through its primary key from its foreign key. Example could be, if an entity department has a primary key of department code and this is present in the employee entity as a foreign key. If the deletion of a department happens not withstanding that particular code's usage in the employee, then this leads to a referential integrity. Entity integrity makes sure that there are no nulls in the primary key of an entity and there are no duplicates of the primary key. Business rules and state their importance Business rules define the real world operation issues and maxims as usable rules for a software designer. These rules are also called integrity rules2 and they control the database. When a schema is designed, domain constraints, key and relationship constraints apart from other inherent integrity constraints, need to be mentioned. These are the rules that hold the entire database together. Redundancy and Normalization and state their importance One set of data when it gets repeated multiple number of times in a database is called Redundancy. Redundancy is associated with a number of problems. Maintaining data integrity becomes tough since multiple updates needs to be done every time a change is done in the specified data. In some cases, a controlled redundancy could help in saving of space or in quick access. Normalization is a process by which, redundancy is reduced. Undesired relation schemas are broken down into smaller relationship schemas that possess desirable attributes. Normalization exists in five different levels or forms. Higher the normalization form, better the database is with desired attributes. Functional dependency, partial dependency & transitive dependency A functional dependency is a relationship between two attributes in a database. In one entity, there could be attributes which are functionally independent of the other attributes and dependent on certain others. An entity X is said to be functionally dependent on Y, expressed X->Y, if a set of attributes of X and Y are constrained by a relationship. If X is functionally dependent on Y and if any of the attributes of X is removed, then if the functionally dependency is invalid then it is called fully functionally dependent. On the other side, if the functional dependency exists even after removal of an attribute, then it is called partial dependency. A functional dependency X->Y in a relation schema is a transitive dependency if there is a set of attributes Z that is not a subset of any key of R, and both X->Z and Z->Y is valid. E-R diagrams and schema diagrams The description of a database is called schema diagrams. These are generally expressed as entities and their attributes. Whereas, the E-R diagrams specify the relationship between entities and the relationship themselves become attributes. A database schema diagram is given below: Student Number Name Class Major Course Course Course Name Department Hours A typical entity relationship diagram: In Task 2, I find that everything is in place. What is missing is the normalization process; this could be suggested based on the Codd's normalization process. User Requirement Specifications and Design Paper Abstract This report presents the process adopted to solve the case study taken up for URS analysis and design. A museum consisting of five galleries have been taken with classification existing on the place of origin, time of origin and the type of collection. This is being analyzed and the results presented below. Introduction This paper aims at producing a design output for an international museum system design. The model adopted for the design is the object life cycle model which follows the Abbot (1983) proposal. The method adopted follows Yourdon (1991) suggested tables for implementing the object and class identification. The Objectives The objectives of the system would be as follows: 1. Software Systems Design (SSD) and Database. 2. Analysis using ER Diagrams and reach normalization To reach our objectives, the following tools, techniques and methodology shall be adopted: The first step in object model needs to write down a statement for problem definition. The statement covers the overall operation of the system. This would mention the various nouns and verbs that highlight the exact working of the software system. The statement has to reflect: 1. the working, 2. the constraints. From the statement, the nouns and verbs are picked up to populate the Abbott-Yourdon Table. Out of these picked up nouns and noun phrases, verbs and adverbs, supersets of these nouns and verbs are marked out and listed to refine the table further. Typically, date, time are all part of Item; museum can be looked at as a part of the place or a collection. Therefore, museum is also dropped. The refined table is used for further processing. Attributes are defined for every entity. Some of these items could be simple and others could be complex. Complex attributes are defined again with sub-attributes which have similar features as that of the main attributes. Analysis First level of analysis is done using the ER diagram1. Nouns become the entities and verbs become the relationships in the entity diagram. When two entities are connected by a relationship, we indicate what type of relationship exists between them. In other words, we indicate the connectivity. Connectivity helps in understanding the type of relationship whether it is one to many, one to one or many to one. This helps in defining the business rules later. The same is valid when the cardinalities are defined for every relationship. They specify the business constraints that will help in designing the database. Normalization Based on these entities, a complete schema diagram is prepared accompanied by the business rules that could be drawn out of the ER diagram and Abbott-Yourdon Table. For every entity, attributes defining their characteristics is done. Redundancy in the database has to be reduced by using the normalization techniques. All possible normalization levels could be achieved applying the normalization techniques proposed by Codd. In order to do this effectively, functional dependency of the entities are noted. These could be partially dependent, transitive or otherwise. In order to achieve the first normal form, there should be a primary key, all fields in the entity should be dependent on the primary key and there is no repeat value. To achieve second Normal form, in addition to the first normalization of the database, there should not be any partial dependencies existing in the schema. If all the requirements of the second normal form are achieved and if all the transitive dependencies are removed from the schema then the database reaches the third normal form. Conclusion It is quite standard to stop normalization process at third level. This should make the database reasonably efficient to operate. In this process, up to three levels of normalization could be achieved. The database thus realized will be usable and efficient. Bibliography 1. Elmasri & Navathe, Fundamentals of Database Systems, The Benjamin-Cummings Publishing Company Inc., 2003 Read More