











Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An in-depth analysis of risk management in three popular software development lifecycle models: Waterfall, V-Model, and Spiral. It covers the advantages and disadvantages of each model, focusing on risk assessment, calculation of inherent risk, risk assessment reports, and the role of the IT team in risk management. The document also discusses the importance of a project feasibility study and the impact of external risks and internal vulnerabilities on project success.
Typology: Exercises
1 / 19
This page cannot be seen from the preview
Don't miss anything!












Prepared for : Mr. Le Van Minh Greenwich University Da Nang Prepared by: Le Vo Thang 18, November, 2018
Sequential life cycle model : ............................................................................................. 3 1.Waterfall Model :.................................................................................................................. 3 2.V- model : ............................................................................................................................ 6 *** Iterative Model* .................................................................................................................... 10 1.Spiral Model : ..................................................................................................................... 10 2.DSDM model : .................................................................................................................... 12
1.Risk assessment : ................................................................................................................. 15
Waterfall Model – Advantages Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order. Some of the major advantages of the Waterfall Model are as follows : Simple and easy to understand and use Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood. Clearly defined stages. Well understood milestones. Easy to arrange tasks. Process and results are well documented.
Waterfall Model – Disadvantages
- The major disadvantages of the Waterfall Model are as follows : No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model. It is difficult to measure progress within stages. Cannot accommodate changing requirements. Adjusting scope during the life cycle can end a project. Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.
2. 4. Low level design (Module design) : In this steps , the designed system is broken up into smaller modules with the very specification details so the developers can start coding .The module design document will contain a detailed functional of the modules :
2.6. Testing : 2.6.1.Unit Test Plans (UTPs) are developed in module design step would performance now. The unit tests are a very necessary part of any application develop procedure and helps eliminate most of errors that can generate at a very early phase. A unit like a program module is the smallest entity in the whole system. Unit testing check that the module can execute exactly when isolated from the rest of the units of system. 2.6.2.Integration testing : Integration Test Plans are developed in the Architectural Design step. Integration Testing performed to make sure that all of the modules created before which tested independently in UTPs can coexist and communicate among themselves within the system.Then Test results are shared with the client ‘s team. 2.6.3.System testing : System testing is strictly related with the system design stage. Unlike Unit and Integration Testing , System Test Plans are constructed by client's team. System Test plan ensures that all of the client ’s expectations are met. The entire application ’s system is tested for its functionality, interdependency and communication. System Testing authenticates that functional and non-functional requirements are met. Load and performance testing, stress testing, regression testing.Most of the problems about the compatibility beetween hardware and software can be discovered during this step. 2.6.4.Acceptance testing: User Acceptance Test (UAT) Plans are developed in the Requirements Analysis step. Test Plans are constructed by the user. UAT is executed in user environment and using realistic data to find out the incompatibility with the other systems. UAT confirms that complete system meets all the requirement of user and ready for use in actual time. It also detects the non-functional errors such as load and performance defects in the real time user environment.
1.Spiral Model : The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals. 1.1 Identification This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase. This phase also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral, the product is deployed in the identified market. 1.2 Design The Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and the final design in the subsequent spirals. 1.3 Construct or Build The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral, when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback. Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to the customer for feedback.
1.4. Evaluation and Risk Analysis Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback. The following illustration is a representation of the Spiral Model, listing the activities in each phase. Based on the customer evaluation, the software development process enters the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iterations along the spiral continues throughout the life of the software.
Changing requirements can be accommodated. Allows extensive use of prototypes. Requirements can be captured more accurately. Users see the system early. Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
Management is more complex. End of the project may not be known early. Not suitable for small or low risk projects and could be expensive for small projects. Process is complex Spiral may go on indefinitely. Large number of intermediate stages requires excessive documentation.
*The Pros of DSDM model : 1.RESPONDING TO CHANGE The biggest advantage of this model is responding to change and focus on working on importance part of projects. An Agile team has a list of the most important things they can work on; when they finish the most important thing on that list, they move to the next most important thing…and repeat again and again. This type of focus has many benefits:
*The Cons of DSDM Development LACK OF UNDERSTANDING The biggest drawback of Agile development is most people don’t understand what it means to be Agile. Many companies “want” to be Agile, but don’t invest the time, money, or effort to actually educate management or employees about how the principles apply and what methodologies will work best within their culture and organization With the change in process or people, not investing in understanding why we’re making the change so that change will almost inevitably lead to failure. FLEXIBILITY CAN LEAD TO BAD BEHAVIORS The flexibility of Agile model can lead teams engaging in bad behaviors, and “blaming” the resulting outcomes on Agile itself, rather than the wrong choices made by the team. No product can succeed without some level of process and tools, some negotiation of deliverables or some form of plan.when a company decides to change to Agile model, it rely on internal people with “experience” that lead the change; if their experience is based on poor fundamentals, then their next Agile processes will suffer many of the same limitations.
In recent years, there have been many attempts at building scalable Agile system architectures. These concepts have been driven primarily by the difficulty of effectively scaling the work teams do into larger and larger organizations. When the ideal size of a scrum team is most often positioned at between 5 and 9 people and your development team consists of 500 developers, how do you manage the interrelationships between those small teams while still maintaining a cohesive approach? Most Agile methodologies were designed for small, nimble,young organizations to adopt and adapt, but only in recent years have there been real efforts to identify and establish scalable Agile practices large organizations can apply.
There are different kinds of risk assessment reports. Detail - Risk Report : detail risks at different stages based on cost, schedule, resource and manpower factors. Scope - Risk Report: The scope statement or mission statement may be assessed for risks at the beginning of a projec. Cost Evaluation Risk Report: Cost or funds are at constant risk in a project. It has to be maintained and controlled with as little deviation as possible from the forecasted values.. Schedule Evaluation Risk Report: Time is luxury that a project cannot afford. It is imperative that time schedules are met with as little delay as possible. Time delays can impact the progress of a project and put it at risk. Such risks are documented in the schedule evaluation risk report. Technical Evaluation Risk Report: Risks related to resources, manpower and departments fall under this category. Risks arising due to quality constraints and those which are due to design errors and poor planning also fall under this group.
(1) Senior management‘s commitment. (2) The full support and participation of the IT team (3) The competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization. (4) The awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization.
A project feasibility study is a comprehensive report that examines in detail the five frames of analysis of a given project. It also takes into consideration its four Ps, its risks and POVs, and its constraints (calendar, costs, and norms of quality). The goal is to determine whether the project should go ahead, be redesigned, or else abandoned altogether. The five frames of analysis are: The frame of definition; the frame of contextual risks; the frame of potentiality; the parametric frame; the frame of dominant and contingency strategies. The four Ps are traditionally defined as Plan, Processes, People, and Power. The risks are considered to be external to the project (e.g., weather conditions) and are divided in eight categories: (Plan) financial and organizational (e.g., government structure for a private project); (Processes) environmental and technological; (People) marketing and sociocultural; and (Power) legal and political. POVs are Points of Vulnerability: they differ from risks in the sense that they are internal to the project and can be controlled or else eliminated. A feasibility study examines the practicability of a proposal or idea. The principal function of this is to determine if the project will continue or not. In business, feasibility studies work in a number of reasons. The feasibility report will look at how a certain proposal can work in a long-term basis or endure financial risks that may come. It is also helpful in recognizing potential cash flow. Another important purpose is that it helps planners focus on the project and narrow down the possibilities. Accordingly, a feasibility study can provide reasons not to pursue the said project or proposal. When it comes to the operational aspect, the analysis determines whether the plan has the necessary resources for it to be practicable. Feasibility report will also help we figure out whether or not the people will support the subsequent product or service. Additionally, it provided knowledge on the trends because a feasibility study looks at the present-day market and studies the anticipated growth of your target business sector. Feasibility studies are prevalent in all business industries. Whether Hotel, Hospitality, Restaurant, Real Estate, Medical, Office or Industrial. Getting a head start on a Feasibility study will ensure you save time and money on the project.
- www.tutorialspoint.com. (2018). **SDLC Quick Guide****. [online] Available at: https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm [Accessed 19 Nov. 2018].