Download News Portal Management system and more Study Guides, Projects, Research Software Project Management in PDF only on Docsity!
PRACTICAL :
AIM: Study the complete software development life cycle & analyze various activity
conducted at various phases.
OBJECTIVE: To study various phases of SDLC and different models in detail.
DESCRIPTION:
SDLC
SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.
Various phases of SDLC:
Stage 1: Planning and Requirement Analysis Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.
Stage 2: Defining Requirements Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through SRS. Software Requirement Specification document which consists of all the product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the product architecture SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification. This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity , budget and time constraints , the best design approach is selected for the product. A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.
Stage 4: Building or Developing the Product In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle. Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers etc are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.
Stage 5: Testing the Product This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometime product deployment happens in stages as per the organizations,business strategy.
SDLC Models
There are various software development life cycle models defined and designed which are followed during software development process. These models are also referred as "Software Development Process Models". Each process model follows a Series of steps unique to its type, in order to ensure success in process of software development. Following are the most important and popular SDLC models followed in the industry:
Product definition is stable. Technology is understood and is not dynamic. There are no ambiguous requirements. The project is short.
2] Iterative Model design
2.1 Define: Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).
2.2 Diagram:
Iterative and Incremental development is a combination of both iterative design or iterative method and incremental build model for development. "During software development, more than one iteration of the software development cycle may be in progress at the same time." and "This process may be described as an "evolutionary acquisition" or "incremental build" approach." In incremental model the whole requirement is divided into various builds. During each iteration, the development module goes through the requirements, design, implementation and testing phases. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is ready as per the requirement. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification & testing of each version of the software against those requirements within each cycle of the model. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.
Applications of Iterative Model Requirements of the complete system are clearly defined and understood. Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time. There is a time to the market constraint.
Practical: 2
AIM: Consider any project to be developed in any technology. Construct software requirement specification document.
1. Introduction:
The development of portal for web based newspaper generally means creating a website in which the management of all news item sent by crowd about any type of news & activities are done by the administrator where all people (viewers) can view and know all the relevant information about the knowledge which they seek. This project is about the designing of a newspaper which displays the news which a normal person wants to show. This portal is designed by using HTML, PHP, & CSS technologies and SQL Server. The portal has basically three user parts where one is registered user (authentication required) who can view, add comment can have general discussion with another user and another is administrator (has an authentication) who will manage or control the website and other user (no authentication required) can only view and search. The following subsections of the Software Requirements Specifications (SRS) document provide an overview of the entire SRS.
Purpose
The main purpose of the project is intended to develop a portal for management of Web based news. The portal provides a suitable and easy display for which large population around the world can learn or will have the knowledge about the world. Basically this is a crowd sourcing newspaper. Online news portal aims in digitalizing our daily life as it is used to keep us updated with all the daily news updates. It provides us the detailed news alerts digitally so we can get rid of newspapers. This project has many different features which are not available in normal online news websites. This provides Facility to users to have discussions with others.
Overview
The SRS is organized into two main sections. The first is The Overall Description and the second is the Specific Requirements. The Overall Description will describe the requirements of the WBNP from a general high level perspective. The Specific Requirements section will describe in detail the requirements of the system.
Definitions
SRS – Software Requirements Specification WBNP – Web Based News Portal End users – The people who will be actually using the system
2. Goal of Implementation
Online news portal is a digitalized system which helps users to get daily news alerts & updates online.
Free of cost Get rid of newspapers
R2.1: Select search option Input: Search option. Output: User will be prompted to enter the search topic.
R2.2: Check for the search topic Input: Checks for the search topic related item. Output: We will be prompted to display the items.
R2.3 Display the item Input: Enter topic related to item. Output: Display the item.
Processing: It checks for any item related to the search topic and displays it on the screen and if there is no item related to the topic is present then it will pop as no related item.
R3: Edit topic Description: Edit function can be done by only administrator or editor. Any uploaded item is examined and edited by administrator so it can be allowed to display to mass.
R3.1: Select edit option Input: Edit option. Output: User will prompt to edit the uploaded item.
R4: User registration Description: Registration is allowed to the users who are not registered yet (unregistered users) and completion of this function they can also upload items.
R4.1: Select register option Input: Register option. Output: User will prompt to write a user name, email id, and password.
R4.2: Check for validity Input: Checks whether any other registered users have same information. Output: We will be prompted to register successfully if it has different information or else it’s rejected.
Processing: It checks if the information submitted about the new user is similar to any other registered user if yes it rejects the user information if no then new user will be registered successfully.
4. Non-functional Requirements
These are the requirements that are not functional in nature. Especially these are the constraints the system must work within.
Performance Requirements: The system response time must be less than 30 seconds for the user interface. Or else the system will show TIMED OUT. Reliability Requirements: The system shall have a minimum uptime of 99 % excluding time pre-scheduled for maintenance and/or upgrades. Safety Requirements: All the system data must be backed up every day and the backup copies stored in another server at different location for disaster recovery.
Quality Attributes: The source code for the system is well documented for ease of maintenance and upgrading the system in future.
External Interfaces
The Web Based News Portal will use the standard input/output devices for a personal computer. This includes the following:
Keyboard Mouse Monitor Printer
Software Interfaces
The system shall interface with any Web Browser easily and on any Operating System like mac, android and Microsoft etc.
Hardware Interfaces
The system shall run on any smart devices like laptop, pc, mobile, tablet etc.
5. Behavioral description
Design Constraints
The WBNP System shall be a stand-alone system running in a any of environment like Microsoft, android, mac etc. The system shall be developed using HTML,PHP,CSS and SQL database.
Availability
The system shall be available 24 hours 7 days of week.
Practical: 3
AIM: Decide which process model to be used for development. Process model description
& why this model suitable for your project.
DESCRIPTION:
Incremental Model
In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed modules. Incremental model is a type of software development model like V- model, Agile model etc.
In this model, each module passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first module, so you have working software early on during the software life cycle. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.
Advantages of Incremental model:
Generates working software quickly and early during the software life cycle. This model is more flexible – less costly to change scope and requirements. It is easier to test and debug during a smaller iteration. In this model customer can respond to each built.
Lowers initial delivery cost. Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:
Needs good planning and design. Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. Total cost is higher than waterfall.
When to use Incremental model
This model can be used when the requirements of the complete system are clearly defined and understood. Major requirements must be defined; however, some details can evolve with time. There is a need to get a product to the market early. A new technology is being used Resources with needed skill set are not available There are some high risk features and goals.
Why is this model suitable for my project?
In our project the basic requirements are clear so we can develop a basic software. First only a basic online web portal for news will be delivered Then with time new modules will be added according to the feedback. With time there will not be much changes in the requirements for the system so there is no problem in using this model.
knowledge which they seek. This project is about the designing of a newspaper which displays the news
which a normal person wants to show. This portal is designed by using HTML,
PHP, & CSS technologies and SQL Server. The portal has basically three user parts where one is registered
user (authentication required) who can view, add comment can have general discussion with another user
and another is administrator (has an authentication) who will manage or control the website and other user
(no authentication required) can only view and search.
The website consists of basic pages from which the user can view and know the relevant
Information like history, upcoming. In other case, the administrator manages all the relevant
Actions for which the users can view properly and also make reports.
C) Performance Issue
The major issue is to deliver a complete whole portal which is not possible within little time and with RAD
model so deliverables are broken down in the project plan into smaller deliverables and activities.
Factors critical in deciding the performances of the software are:
Internet Connection Being predominantly a web based application, fast internet connection is necessity. Slow connections may hamper performance.
Server performance Performance may also be hampered by excessive net traffic.
D) Management and technical constrains
The project should be completed within specified time period including Planning, Designing, Development, Testing and Deployment. The project should be completed within specified budget. The Requirement Traceability Matrix (RTM) should be correlated and completed. All the Entry and Exit criteria of all the stages should met. The product should be user-friendly, reliable and should maintain the industry standards without compromising the quality. The system architecture and design should be open and in a standard way such that additional functionalities can be added later without much effort. Database designed should me normalized. Transfer of rupees for booking tickets should be done through secured connection.
2. Project Estimates:
Estimation technique for project
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm 1981. Boehm postulated that
any software development project can be classified into a one of the following categories based on
development complexity: organic, semidetached and embedded. In order to classify a product into the
identified categories, Boehm requires us to consider not only the characteristics of the product but also
of the development team and the development environment. Roughly speaking, the three product classes
correspond to application, utility and system programs, respectively. Normally data processing programs
are considered to be application programs. Compilers, linkers etc. are utility programs. Operating
systems and real time system programs etc. are system programs. System programs interact directly with
the hardware and typically involve meeting timing constraints and concurrent processing.
Also the utility programs are three times as difficult to write as application programs and, system
programs are roughly three times as difficult as utility programs. Thus, the relative levels of product
development complexity for the three categories (application, utility and system programs) of products
are 1:3:9.
Boehm’s [1981] definitions of organic, semidetached and embedded systems are elaborated as follows:
- Organic: We can consider a development project to be of organic type, if the project deals with developing a well understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects.
- Semidetached: The project can be considered of this type is the development team consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems but may be unfamiliar with some aspects of the system being developed.
- Embedded: The project can be considered of this type, is the software being developed is strongly coupled to complex hardware, or if stringent regulations on the operational procedures exist. Here we have chosen the embedded model since all the team members are new in the field of the software development and also the software product size is relatively small.
3. Schedule:
(A) Work breakdown structure In order to execute the task successfully we need to follow the work break down structure.
Work Breakdown Structure A work breakdown structure can be defined as dividing the whole project into individual components in a hierarchical structure. The breakdown structure defines tasks that can be completed independent of other tasks, resource allocation and assigning the responsibilities of resources in the project.
Online News Portal System:
a. Description i) Brief of project ii) Define stakeholders b. Achieve goal i) Scope ii) Requirements iii) Research iv) Explore v) Consult vi) Concept development vii) Plan c. Design i) Develop OHS regulation ii) Human resource iii) Budgeting iv) Finalize v) Approval of budget vi) Approval of plan vii) Re-approval in requirement d. Implementation i) Coding ii) Unit testing e. Testing i) Final commotion ii) Testing phase 1 iii) Testing phase 2 f. Installation and deployment i) installation g. Evaluation i) Review ii) Feedback iii) Report
A) Gantt Chart
Online News Portal System
Description Goal^ Design Implementation^ Testing Installation^ Evaluation
-Brief of Project.
-Define Stakeholders
S -Scope
Requirem ents -Research E -Explore -Consult
-Developing -Human resource -Budgeting -Finalize Approvalof
-Coding
-Unit Testing
-Final Commotion
-Testing 1
-Install
-Deployment
-Review
-Feedback
-Report
For developing this application the resources being used are: Php Wamp server MySql
Dreamweaver (Designing Webpages)
5. Staff Organization:
Team Structure
Democratic team structure is used, as the name implies there is no project manager. All are treated as team leaders and all of them can give any suggestions for the project development. Everyone is given equal rights for making and giving changes which are beneficiary for the project. Democratic organization leads to higher morale and job satisfaction. Consequently, it suffers from less man-power turnover. As team is of less than 5 engineers, democratic team structure is suitable for project and for research-oriented projects.
6. Risk Management:
A) Risk Analysis:
1) Product Size Risks
Estimated size of product in number of programs, files, transactions
Size of database created or used by the product. Number of projected changes to the requirements for the product before delivery and after delivery.
2) Business Risks
Amount and Quality of product documentation that must be produced and delivered to the customer. Delivery deadlines Costs associated with late delivery and defective product.
3) Client Risks
Communicating with developers
Will customer agree to spend time in formal requirements gathering meetings to identify project scope. When working for the first time
4) Resource Risks
Number of Resources and skillsets
5) Technology Risks
Requirements put excessive performance constraints on the product Customer demanding new technology.
B) Risk identification:
Risks with respect to the work to be done Miscommunication Time out Design errors Illness or absence of team members Server crash
Risks with respect to the management Illness or sudden absence of the project manager
Risks with respect to the resources Unavailability of the technical advisor when needed
Risks with respect to the customer. The customer changes his mind about the requirements The customer is not available when needed
The Risk Manager is responsible for identifying risks and monitor risk. After identifying Risk Manager
Need to solve problem by replace old system with new one. If need arise Risk Manager should modify,
delete and add information to the database.
C) Risk Estimation:
-Risk estimation also called risk projection, attempts to rate each risk in two ways:
The likelihood or probability that the risk is real.
