Le Vo Thang – GCD17011.docx – PDFCOFFEE.COM

Mục lục bài viết

Citation preview

1

Software Development Life Cycle Assignment 1

Prepared for :

Mr. Le Van Minh

Greenwich University Da Nang

Prepared by: Le Vo Thang

18, November, 2018

2

Table of Contents P1. Describe two iterative and two sequential software lifecycle models.

*Sequential life cycle model : ………………………………………………………………………………… 3 1.Waterfall Model :…………………………………………………………………………………………………… 3 2.V- model : ……………………………………………………………………………………………………………. 6

* Iterative Model ……………………………………………………………………………………………………..10 1.Spiral Model : ………………………………………………………………………………………………………10 2.DSDM model : ……………………………………………………………………………………………………..12

P2. Explain how risk is managed in the Spiral lifecycle model. 1.Risk assessment : …………………………………………………………………………………………………..15 2. Calculating Inherent Risk : ……………………………………………………………………………………….15 3.Risk assessment reports: ………………………………………………………………………………………….16 4. Keys for a successful risk management program : ………………………………………………………16

P3.Explain the purpose of a feasibility report

17

P4 .Describe how technical solutions can be compared.

18

REFERENCES

19

3

P1. Describe two iterative and two sequential software lifecycle models. *Sequential life cycle model : 1.Waterfall Model : *The sequential phases in Waterfall model are : 

Requirement Gathering and analysis − The requirements of the system are captured in this phase and documented in a requirement specification document.

System Design − The requirement document in first phase are studied in this phase and the system design is prepared. This system design helps defining the overall system architecture.

Implementation − The system is first developed unit functions, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.

Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.

Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

4

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.

5

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.

6

2.V- model : 2.1. Business requirements :

In this first step, business analysts gathering information about the needs of the user(client) by interview or meeting. Then the document called the user requirements is created. The user requirements document describe all information of the application : the interface, data, security, system ‘s functional, performance. The users will carefully review this document because it would serve as the guideline for the system designers in the system design stage. The user acceptance tests are also designed in this step.

2.2 System requirements : After analyze and understand the detailed requirements document, it is the time to design the complete system. System engineers calculate possibilities and techniques that can be performed follow the user requirements.If any of the requirements are inappropriate , the user is notified of the problem.Then the resolution is suggested and the requirements document is edited after that.In this step, the application specification document is generated for the development stage.It contains the general, menu structures, data structures system organization.The system test plan is developed in this step, the earlier the system test plan is prepared , the more time for unit testing executed later.

2.3. High level design (Architecture design) : Based on the technical and financial possibility , software architects would realize the system design by broken down it into modules taking up different functionality, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details . The integration tests would be designed in this stage.

7

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 : + All elements of the database tables. + All interface details with complete API references. +All dependency issues +Error message listings +Complete input and outputs for a module. It is very important that the module designed is appropriate with the other modules in the system construction and the the other external systems.The unit tests can be developed in this stage based on the internal module designs.

2.5.Coding : All of the modules design is convertered into code by the developers in this step. The most suitable programming language is decided according to the system and architecture requirements. The coding is implemented based on the coding guidelines and standards. The code is went through numerous code reviews and finally optimized for the best performance. Unit testing is executed by the developers on the code written by them.

8

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.

9

*V-Model – Pros and Cons

-The advantages of the V-Model method are as follows

This is a highly-disciplined model and Phases are completed one at a time.

Works well for smaller projects where requirements are very well understood.

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.

-The disadvantages of the V-Model method are as follows

High 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.

Once an application is in the testing stage, it is difficult to go back and change a functionality.

No working software is produced until late during the life cycle.

10

* Iterative Model 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.

11

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.

The advantages of the Spiral SDLC Model are as follows 

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.

The disadvantages of the Spiral SDLC Model are as follows 

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.

12

2.DSDM model : Dynamic systems development method (DSDM) was first created in 1994 and originally sought to provide some discipline to the rapid application development (RAD) method. DSDM Atern is the latest version of the popular Dynamic Systems Development Model approach to Agile. It Eliminates problems of: Going over-budget, Missing deadlines, Users not involved, Management not commited in the project.

-The night principles of DSDM : 1. Active user involvement 2. Teams must be empowered to make their own decisions. 3. Frequent releases more important than maximizing quality. 4. Primary criteria for deliverables is meeting business needs. 5. Iterative development is essential to reach correct solution. 6. Any change during development can be reversed. 7. The most high level requirements should be unchangeable. 8. Testing shall occur throughout the lifecycle of the project. 9. All stakeholders must cooperate and communicate.

13

*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: -Customers get solutions to the problems they value most in the earliest time. -Developers feel valued, since they’re working on things that actually matter and will receive frequent in-depth feedback from the very people using the product.

2.ACCEPTING UNCERTAINTY

During the project we may find a particular technical solution doesn’t meet the needs of customers, or we might discover there’s an entirely different problem underneath the stated problem. Applying Agile principles to our approach allows us to accept the unknown and prioritize discovery and experimentation to drive out uncertainty before we fully commit to a solution.

3. FASTER REVIEW CYCLES To ensure that new discoveries are contemplated and current efforts are evaluated. Most Agile practices either time-box efforts (Scrum) or control the amount of “work in progress” to ensure efforts are completed within a reasonable amount of time. Those efforts are then reviewed with customers .

14

*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.

CHALLENGES AT SCALE 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.

15

P2. Explain how risk is managed in the Spiral lifecycle model. -An effective risk management process is an important component of a successful IT security program. .The risk management process should not be treated primarily as a technical function carried out by the IT experts who operate and manage the IT system, but as an essential management function of the organization. The principal goal of an organization‘s risk management process should be to protect the organization and its ability to perform their objectives..

1.Risk assessment : Risk assessment is the first process in the risk management methodology.Using risk assessment to determine the extent of the potential threat and the resulting impact of that adverse event on the organization. Consequence is the level of impact that the potential risk event can have on the achievement of business objectives..5 level rating scale in the risk survey including : 25-Almost Certain, 20-likely, 15-Possible, 10Unlikely, 5-Rare. .

2. Calculating Inherent Risk : Inherent risk specify the exposure arising from a risk event before any action has been taken to manage it. Inherent Risk = Consequence X Probability Inherent risk rating will be exhibited on a 4 level rating scale : Extreme Risk, High Risk, Moderate Risk, Low Risk.

16

3.Risk assessment reports: 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.

4. Keys for a successful risk management program : (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.

17

P3.Explain the purpose of a feasibility report. 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.

18

P4 .Describe how technical solutions can be compared. An alternative matrix can be used to organize the pros and cons of the design alternatives so that the best solution will be chosen in the end. This matrix is created using the same steps as the feasibility analysis. The only difference is that the alternative matrix combines several feasibility analyses into one matrix so that the alternatives can easily be compared. An alternative matrix is a grid that contains the technical, budget, and organizational feasibilities for each system candidate. Sometimes weights are provided for different parts of the matrix to show when some criteria are more important to the final decision.To create the alternative matrix, draw a grid with the alternatives across the top and different criteria (feasibilities, pros, cons,…) along the side. Next, fill in the grid with detailed descriptions about each alternative. This becomes a useful document for discussion because it clearly presents the alternatives being reviewed and comparable characteristics for each one.

Figure 1 : Alternative matrix comparison.

19

REFERENCES -www.tutorialspoint.com. (2018). SDLC Quick Guide. [online] Available at: https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm [Accessed 19 Nov. 2018]. -UserVoice Blog. (2018). The Pros and Cons of Agile Product Development | UserVoice Blog. [online] Available at: https://community.uservoice.com/blog/the-pros-and-cons-of-agile-productdevelopment/ [Accessed 19 Nov. 2018]. -Ijera.com. (2018). [online] Available at: https://www.ijera.com/papers/Vol2_issue4/DJ24712716.pdf [Accessed 19 Nov. 2018]. -En.wikipedia.org. (2018). Feasibility study. [online] Available at: https://en.wikipedia.org/wiki/Feasibility_study#Formal_definition [Accessed 19 Nov. 2018]. -Trumanmox.com. (2018). Why a Feasibility Study is Important for any Business | TrumanMox. [online] Available at: https://www.trumanmox.com/why-a-feasibility-study-is-important-for-anybusiness [Accessed 19 Nov. 2018]. -Arxen.com. (2018). [online] Available at: http://www.arxen.com/descargas/PulzarCloud/Books/systems-analysis-and-design-with-uml-5thedition.pdf [Accessed 19 Nov. 2018].