Font size
WorksheetsSWENG
Total questions: 155
Worksheet time: 2hrs 26mins
A (a) should be made to understand the problem
before a software solution be developed.
Design has become a (a) .
Software should exhibit a (a)
Software should be (a)
instructions (computer programs) that when executed provide desired features, function, and performance
(a)
data structures that enable the programs to adequately manipulate information
(a)
descriptive information in both (a) that describes the operation and use of the programs.
A collection of programs written to service other programs
(a)
Stand-alone programs that solve a specific business need
(a)
A broad array of “number-crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology
(a)
Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself.
(a)
Composed of reusable components and designed to provide specific capabilities for use by many different customers
(a)
This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices
(a)
Makes use of heuristics to solve complex problems that are not amenable to regular computation or straightforward analysis.
(a)
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software
(a)
is a collection of activities, actions, and tasks that are performed when some work product is to be created.
(a)
strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied.
(a)
(e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model)
(a)
focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome
(a)
establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. 4 Construction 5 Deployment
(a)
PROCESS FRAMEWOKRS
(a)
Allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule
(a)
Assesses risks that may affect the outcome of the project or the quality of the product.
(a)
Defines and conducts the activities required to ensure software quality.
(a)
Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.
(a)
Defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities
(a)
Manages the effects of change throughout the software process
(a)
Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components
(a)
Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.
(a)
Understand the problem (communication and analysis). Plan a solution (modeling and software design). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance).
(a)
software process models (a) that define the processes, activities, actions and tasks involved in software development
provide a structured approach to guide software engineers and development teams through the entire software development life cycle
(a)
Each process model outlines a set of steps to be followed, helping to organize and streamline the development process
(a)
Process models typically organize the software development life cycle into (a) , where each phase represents a set of related activities. These phases often include requirements analysis, design, implementation, testing, deployment, and maintenance.
Within each phase, specific ___________ are defined. These ______ describe what needs to be done, and _______ provide detailed steps for accomplishing those _______
(a)
Process models identify the _____ required for each phase, such as project requirements or design specifications, and the corresponding ______ produced at the end of each phase, such as executable code or documentation
(a)
Software process models specify the ____________ of individuals or teams involved in the development process. This ensures clarity regarding who is _____ for which tasks and activities
(a)
Some process models incorporate feedback loops, allowing for the revisiting of previous phases based on feedback from later stages. This iterative approach is common in agile and incremental models
(a)
While some models follow a rigid, sequential structure (e.g., Waterfall model), others are more (a) , accommodating changes in requirements and incorporating feedback throughout the development process (e.g., Agile model)
is one of the earliest and most straightforward process models used in software development
(a)
who proposed waterfall model and when
(a)
it is a linear and sequential approach to software development, where progress is seen as flowing steadily downwards through phases
(a)
each phase in the model must be completed before moving on to the next one and the process is generally non-iterative
(a)
in this initial phase, the project team must work closely with stakeholders to gather and document all project (a) and it serves as the foundation for the entire development process
in waterfall model, once the requirements are clear, the ________ phase begins. The system architecture software _____, and overall structure are planned and documented
(a)
in waterfall model, the actual coding of the software takes place in this phase
(a)
in waterfall model, the software is rigorously tested to identify and rectify any defect or issues
(a)
in waterfall model, this phase involves installing the software and making it available for end-users
(a)
in waterfall model, ongoing support and updates are provided as needed. this may include fixing bugs, addressing user feedback, and incorporating enhancements
(a)
was introduced to address some of the limitations of the sequential approach in the waterfall model
(a)
this model emphasizes the importance of early testing and validation activities, aligning them with corresponding development phases
(a)
in v-model, corresponding testing activities include the creation of test plans and test scenarios based on the (a)
in v-model, testing activities involve creating test cases based on the design specifications
(a)
in v-model, the high-level design of the system is established. testing activities are verifying the (a) against requirements
in v-model, is the detailed design of individual (a) or components is carried out. testing activites includes preparing test cases for unit testing
in v-model, the actual coding of the software is done. corresponding testing activities include unit testing to ensure that each module functions as intended
(a)
in v-model, indvidual modules or components are tested in isolation. this is the first phase of actual testing in v-model
(a)
in v-model, modules are combined and tested as a group and this phase checks for interactions between (a) -- components
the complete (a) is tested as a whole to ensure that it meets the specified requirements
the software is tested to verify whether it satisfies the (a) criteria defined by the stakeholders
is an iterative software development approach where the development process is divided into smaller, manageable parts.
(a)
this model combines the elements of the waterfall model with the flexibility of iterative prototyping
(a)
in incremental model, initial system (a) are analyzed, and the overall scope of the project is defined
in incremental model, the first increment is designed and developed based on the initial set of requirements. this increment represents a functional subset of the complete system
(a)
in incremental model, the first increment undergoes testing to ensure that it meets the specified requirements and is free from defects
(a)
in incremental model, additional increments are designed and developed, each building upon the functionalities of the previous increments
(a)
in incremental model, each new increment undergoes testing, and testing activities for previous increments continue to ensure overall system reliability
(a)
in incremental model, increments are integrated to form the complete system. integration testing is performed to validate the interactions between different increments
(a)
in incremental model, the complete system undergoes final testing to ensure that all increments work seamlessly together
(a)
is a software development life cycle model that combines elements of the waterfall model and iterative development methodologies
(a)
when and who proposed spiral model
(a)
particularly well-suited for projects with a high level of risk and uncertainty
(a)
emphasizes the importance of risk assessment and management throughout the software developement process
(a)
in spiral model, determine project objectives, constraints, and requirements. Identify potential risks and develop strategies for risk management
(a)
in spiral model, evaluate identified risks and prioritize them based on severity. Develop strategies to mitigate or manage these risks effectively
(a)
in spiral model, develop and implement the software based on the requirements. This phase includes coding, testing, and integration activities
(a)
in spiral model, assess the results of the testing phase and obtain feedback from stakeholders.
(a)
a software development approach that involves the creation of an initial, partial implementation of a system to gather user feedback and refine the system through successive iterations
(a)
This software process model methodology is characterized by its focus on rapid, incremental development with an evolving understanding of user requirements
(a)
in evolutionary prototyping, gather and understand the initial set of requirements from stakeholders. These requirements serve as a foundation for the development of the initial prototype
(a)
in evolutionary prototyping, create a basic, functional prototype based on the identified requirements. This prototype is developed quickly and may not include all features of the final system
(a)
in evolutionary prototyping, allow users to interact with the initial prototype and gather their feedback. Users provide insights into their preferences, requirements, and any issues they encounter
(a)
in evolutionary prototyping, based on user feedback, refine the prototype to address identified issues and enhance functionalities. This marks the beginning of iterative cycles, with each cycle contributing to the evolution of the system
(a)
in evolutionary prototyping, throughout the prototyping process, maintain ongoing communication with users. Their involvement is crucial for shaping the system according to their needs and expectations
(a)
in evolutionary prototyping, continue the refinement and iteration process until the final system meets user satisfaction
(a)
is a software development methodology that prioritizes flexibility, collaboration, and customer satisfaction
(a)
it emphasizes iterative and incremental development, allowing teams to respond to changing requirements and deliver valuable software in shorter time frames
(a)
contrasts with traditional, plan-driven approaches by promoting a more dynamic and customer-centric development process
(a)
in agile model, development is carried out in small, iterative cycles. Each iteration delivers a potentially shippable increment of the product, allowing for continuous improvement.
(a)
in agile model, teams are composed of individuals with diverse skills (developers, testers, designers) who work collaboratively to deliver a complete, functional product
(a)
in agile model, a prioritized list of features, enhancements, and tasks that need to be addressed during the development process. It is dynamic and evolves based on changing requirements and priorities
(a)
a concept and practice in agile model, short, user-focused descriptions of a piece of functionality. (a) help articulate end-user requirements and guide development efforts
a concept and practice in agile developement, fixed time-boxed development cycles, typically lasting 1 to 4 weeks, during which a specific set of features is developed, tested, and delivered
(a)
a concept and practice in agile model, brief, daily team meetings to discuss progress, challenges, and plans. These meetings enhance communication and collaboration within the team
(a)
a concept and practice in agile model, emphasizes frequent integration of code changes and the automated delivery of software to production environments. This ensures a more streamlined and efficient development process
(a)
a concept and practice in agile model, regularly scheduled meetings where the team reflects on their processes, identifies areas for improvement, and implements changes to enhance efficiency
(a)
is a management framework that teams use to self-organize and work towards a common goal. It describes a set of meetings, tools, and roles for efficient project delivery
(a)
is a popular framework used to implement agile and DevOps software development. It requires real-time communication of capacity and full transparency of work
(a)
an agile software development framework that aims to produce higher quality software and higher quality of life for the development team. (a) is the most specific of the agile frameworks regarding appropriate engineering practices for software development.
is a framework that provides a structured yet flexible way for teams to work collaboratively on complex projects
(a)
Work is organized into time-boxed iterations called sprints, typically two to four weeks long
(a)
a visual management method that emphasizes continuous delivery and flow of work
(a)
Encourage active stakeholder participation by matching their availability and valuing their input
requirements
architectural design
resource estimation
Use simple models (e.g., Post-it notes, fast sketches, user stories) to reduce barriers to participation
requirements
architectural design
resource estimation
Take time to explain your requirement representation techniques before using them
requirements
architectural design
resource estimation
Adopt stakeholder terminology, and avoid technical jargon whenever possible
requirements
architectural design
resource estimation
Use a breadth-first approach to get the big picture of the project done before getting bogged down in details
requirements
architectural design
resource estimation
Allow the development team to refine (with stakeholder input) requirement details “just in time” as user stories are scheduled to be implemented
requirements
architectural design
resource estimation
Treat the list of features to be implemented like a prioritized list, and implement the most important user stories first
requirements
architectural design
resource estimation
Collaborate closely with your stakeholders and only document requirements at a level that is useful to all when creating the next prototype
requirements
architectural design
resource estimation
Question the need to maintain models and documents that will not be referred to in the future
requirements
architectural design
resource estimation
Make sure you have management support to ensure stakeholder and resource availability during requirements definition
requirements
architectural design
resource estimation
Question the need to maintain models and documents that will not be referred to in the future
requirements
architectural design
resource estimation
Focus on key quality attributes, and incorporate them into prototypes as they are constructed
requirements
architectural design
resource estimation
When planning prototypes, keep in mind that successful software products combine customer-visible features and the infrastructure to enable them
requirements
architectural design
resource estimation
Recognize that an agile architecture enables code maintainability and evolvability if sufficient attention is paid to architectural decisions and related quality issues
requirements
architectural design
resource estimation
Continuously managing and synchronizing dependencies between the functional and architectural requirements is needed to ensure the evolving architectural foundation will be ready just in time for future increments
requirements
architectural design
resource estimation
It is important to understand before you begin whether you have a reasonable chance of delivering software products on time and with acceptable costs before you agree to take on the project
requirements
architectural design
resource estimation
Early estimates run the risk of being incorrect because the project scope is not well defined and is likely to change once development starts.
requirements
architectural design
resource estimation
Estimates made when the project is almost finished do not provide any project management guidance
requirements
architectural design
resource estimation
Use historic data to estimate time to complete each user story.
requirements
architectural design
resource estimation
Organize the user stories into sprints.
requirements
architectural design
resource estimation
Determine the number of sprints needed to complete the product.
requirements
architectural design
resource estimation
Revise the time estimates as use stories are added or deleted
requirements
architectural design
resource estimation
what step in first prototype construction: Transition from paper prototype to software
design
1
7
3
5
what step in first prototype construction: Prototype a user interface
2
4
3
5
what step in first prototype construction: Create a virtual prototype
1
4
3
7
what step in first prototype construction: Engineer your algorithms
1
4
2
5
what step in prototype construction: add input and output to your prototype
3
6
5
4
what step in prototype construction: Test your prototype
3
4
5
6
what step in prototype construction: Prototype with deployment in mind
1
7
2
6
Prototype evaluation best practices: Provide scaffolding when asking for
prototype feedback.
1
2
3
4
5
Prototype evaluation best practices: Test your prototype on the right people.
1
2
3
4
5
Prototype evaluation best practices: Provide scaffolding when asking for
prototype feedback.
1
2
3
4
5
Prototype evaluation best practices: Ask the right questions
1
2
3
4
5
Prototype evaluation best practices: Be neutral when presenting alternatives to
users
1
2
3
4
5
Prototype evaluation best practices: Adapt while testing.
1
2
3
4
5
Prototype evaluation best practices: Allow the user to contribute
ideas
1
2
3
4
6
Revise time and cost estimates for completing development
Determine the risk of failing to meet stakeholder expectations
Get commitment to continue development
GO,NO-GO DECISION: RECOMMENDED SOFTWARE PROCESS
WALA :)
Define new prototype scope.
Construct new prototype.
Evaluate new prototype and include regression testing.
Assess risks associated with continuing evolution
PROTOTYPE EVOLUTION
WALA :)
Perform acceptance testing.
Document defects identified.
Share quality risks with management
PROTOTYPE RELEASE
WALA :)
is defined as the activities needed to keep software operational after it has been accepted and delivered (released) in the end-user environment
(a)
is the reactive modification of software to repair problems discovered after the software has been delivered to a customer’s end user.
(a)
is reactive modification of software after delivery to keep the software usable in a changing end-user environment.
(a)
is the proactive modification of the software after delivery to provide new user features, better program code structure, or improved documentation
(a)
is the proactive modification of the software after delivery to detect and correct product faults before they are discovered by users in the field.
(a)
can be scheduled and planned for
(a)
is often described as firefighting because it cannot be planned for and must be attended immediately for software systems that are critical to the success of the end-users’ activities.
(a)
Understand code before making changes. Test software after making changes. Document changes. Communicate known defects and risks to all stakeholders
maintenance release software
OKS NA YAN BHE
seven traits of software engineer
(a)
psychology of software engineering
(a)
sense of purpose
sense of involvement
sense of trust
sense of improvement
(a)
5 Factors that foster toxic team environment
high frustration that causes friction among team members
a fragmented or poorly coordinated software process
unclear definition of roles on the software team
continuous and repeated exposure to failure
Team Structures
• difficulty of the problem to be solved
• size of the resultant programs in lines of code of function points
• time that the team will stay together (team lifetime)
• degree to which the problem can be modularized
• required quality and reliability of the system to be built
• rigidity of the delivery date
• degree of sociability (communication) required for the project.
team structures
okay
• E-mail
• Texting
• Video conferencing
• Face-to-face
• Social networking tools (Facebook, LinkedIn, Slack, Twitter)
(a)
