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
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. SDLC can apply to technical and non-technical systems.
Typology: Assignments
1 / 72
This page cannot be seen from the preview
Don't miss anything!
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 9 : Software Development Life Cycle Submission date 18/12/2020 Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name Dang An Thanh Student ID GCS Class GCS0805_PPT Assessor name Vo Ngoc Mai Student declaration I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a false declaration is a form of malpractice. Student’s signature THANH Grading grid P5 P6 P7 M3 M4 M5 M6 D3 D
ASSIGNMENT 2 BRIEF Qualification BTEC Level 5 HND Diploma in Computing Unit number Unit 9 : Software Development Life Cycle Assignment title Undertake a Software Development Lifecycle Academic Year 2020 – 2021 Unit Tutor Vo Ngoc Mai Issue date Submission date 18/12/ IV name and date Submission Format: Format: The submission is in the form of 1 document You must use font Calibri size 12, set number of the pages and use multiple line spacing at 1.3. Margins must be: left: 1.25 cm; right: 1 cm; top: 1 cm and bottom: 1 cm. The reference follows Harvard referencing system. Submission Students are compulsory to submit the assignment in due date and in a way requested by the Tutors. The form of submission will be a soft copy posted on http://cms.greenwich.edu.vn/ Note: The Assignment must be your own work, and not copied by or from another student or from books etc. If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you must reference your sources, using the Harvard style. Make sure that you know how to reference properly, and that understand the guidelines on plagiarism. If you do not, you definitely get failed Unit Learning Outcomes: LO3 Undertake a software development lifecycle LO4 Discuss the suitability of software behavioral design techniques Assignment Brief and Guidance:
Task Now your team had been accepted to create the Software to Tune Source. As a member of a development team, your task now is to produce the requirements for Tune Source. You also need to specify the technique(s) or processes you used in order to get these requirements. Task 2 Based on the requirements which established in Task1 provide the following diagrams: Use Case, ERD, DFD.. which can help to identify more clearly about the system you are going to implement. Task 3 Based on your understanding about the Tune Source’s requirements in Task1 and Task 2, show how the requirement can be addressed. Your method could include software behavioral specification methods and reliability and effectiveness of software. Task 4 Your client wants to improve the software quality. Create a report which shows how software quality could be improved from tracing requirements and programmed design.
P a g e | 1 ASSIGNMENT 2 ANSWERS P5 Undertake a software investigation to meet a business need.
1. Identify the stakeholders, their roles and interests in the case study. − Identify Stakeholders is the first process of the Project Communications Management Knowledge Area, and part of the Initiating process group. This process involves identifying and documenting all the stakeholders on the project, including their interests, impact, and potential negative influences on the project. Stakeholder identification should occur as early as possible in the project and continue throughout its life. Figure 1 Identify Stakeholders − In a project, there are both internal and external stakeholders: 1.1. Internal stakeholders: − Internal stakeholders may include top management, project team members, your manager, peers, resource manager, and internal customers. For example, in Tune Source Project: Founders: ✓ John Margolis ✓ Megan Taylor
P a g e | 3 2.1.2. Estimate the time to complete the Tune Source project: E = (a + 4m + b): 6 = (75 + 4 x 98 + 120): 6 = 98 days 2.1.3. Estimate the cost of the Tune Source project: TE = (a + 4m + b): 6 = (2,100 + 4 x 2,500 + 3,000): 6 = 2,517$ 2.2. Scope − Scope cannot be easily defined. The scope of mentioning specific products has been agreed upon by the project owners. Range tolerance may also show under negative range, for example, the project owner wants to develop more items, but if you lack time or money, you can accept it if you don't. produce those goods. Either of these situations might occur when there are essentials that the project must deliver, but there are other items which are discretionary, or can be delivered at a later date without compromising the project's key objectives. 2.3. Quality − The actual quality constraint is quite similar to the scope except that quality focuses on the characteristics of a deliverable product. Quality works in the same mode as the other constraints. For example, if a project is running late or over budget, the project manager may still be able to deliver the expected items - but they might not be tested as thoroughly or some characteristics of that item may be reduced or eliminated. This is how quality operates as a constraint. Some models of the triple constraint triangle use quality instead of scope as the 3rd leg of the triangle. In many classic situations, when time or cost was strained, it was quality - usually through less testing or verification, but sometimes through dropped characteristics - that was compromised. 2.4. Risk − Everyone recognizes the Risk on a project needs to be addressed and managed. We can see that in any project there may be a level of risk that we are simply not willing to live with, or “tolerate.” That is our risk tolerance. Its simplest and most common expression is in examining the probability of significant risks occurring, their potential impact on the project if they do
P a g e | 4 occur, and our degree of willingness to live with those potential consequences. Risk refers to “opportunities” as well as “threats,” and can be applied in a similar manner. 2.5. How SDLC projects use trade-off negotiations to agree constraints. − The trade-off matrix is not a new idea and it is not for agile development. Each product manager is familiar with the three constraint (scope, time, cost). When any of these factors changes, it requires a different trade-off. The trade-off triangle is a useful tool to educate customers and sponsors about the unbreakable relationship between time, scope and cost. Using the swap matrix takes this conversation one step further. It requires the workgroup to recognize the reality of the project by classifying each type of fixed constraint, selecting or adjusting. The trade-off matrix is often used as an internal tool for conversation and agreement by the development team. In the agile world, however, it becomes a much more inclusive conversation, in which sponsors, managers, and users also participate in the conversation and have a vote in the outcome.
3. Definition of project NFRs − While functional requirements define what the system does or must not do, non-functional requirements specify how the system should do it. Non-functional requirements do not affect the basic functionality of the system (hence the name, non-functional requirements). Even if the non-functional requirements are not met, the system will still perform its basic purpose. − If a system will still perform without meeting the non-functional requirements, why are they important? The answer is usability. Non-functional requirements define system behavior, features, and general characteristics that affect the user experience. How well non-functional requirements are defined and executed determines how easy the system is to use, and is used to judge system performance. Non-functional requirements are product properties and focus on user expectations. − There are more examples below, but for now, think about a functional requirement that the system loads a webpage after someone clicks on a button. There should be a related non- functional requirement specifying how fast the webpage must load. Without it, the user
P a g e | 6
4. Definition project of FRs − Functional requirements define the basic system behavior. Essentially, they are what the system does or must not do, and can be thought of in terms of how the system responds to inputs. Functional requirements usually define if/then behaviors and include calculations, data input, and business processes. Figure 3 Functional requirements − Functional requirements are features that allow the system to function as it was intended. Put another way, if the functional requirements are not met, the system will not work. Functional requirements are product features and focus on user requirements. − Functional requirements of tune source are:
5. Relationships between the FRs and NFRs Parameters Functional requirements Non-functional requirements What it is Verb Attributes Requirement It is mandatory It is non-mandatory Capturing type It is captured in use case. It is captured as a quality attribute.
P a g e | 7 End result Product feature Product properties Capturing Easy to capture Hard to capture Objective Helps you verify the functionality of the software. Helps you to verify the performance of the software. Area of focus Focus on user requirement Concentrates on the user's expectation. Documentation Describe what the product does Describes how the product works Type of Testing Functional Testing like System, Integration, End to End, API testing, etc. Non-Functional Testing like Performance, Stress, Usability, Security testing, etc. Test Execution Test Execution is done before non- functional testing. After the functional testing Product Info Product Features Product Properties
6. Discuss the technique(s) you would use to obtain the requirements. − The second phase of the systems development life cycle is analysis phase. The analysis phase is the most important stage in SDLC. A study by project management consulting company, PM Solutions identified the top cause of a troubled project was poor requirements. The 2004 CHAOS report from the Standish Group indicated that project success rates were only 34%, the rest were either challenged or failed. They also noted that poor requirements were very common in project failures, as they listed it third on their list common factors of project failures. Interestingly enough, they noted lack of stakeholder involvement as first on their list. Lack of stakeholder involvement, however, can also be tied into poor requirements. When the stakeholders aren’t heavily involved, or have poor dialogue between the systems analyst, this directly leads to poor requirements. − Poor requirements have a significant impact on the end results of systems or projects. Requirements are the “blueprints” that everyone involved on the project uses to work from.
P a g e | 9
P a g e | 10
recruit?
6.3. Joint Application Development − JAD is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions. Chuck Morris and Tony Crawford, both of IBM, developed JAD in the late 1970s and began teaching
