Question

What are activities in the five core workflows of the unified process? (Requirements workflow, Analysis workflow, Design workflow, Implementation workflow, Test Workflow) Describe different types of risks in software development. What are characteristics of Object-Oriented Paradigm? Describe software life-cycle models. What are metrics used in different aspects of software engineering? 1. 2. 3. 4. 5.

Good afternoon

Can you help me solve this problems 1-5

With your expertise

It's for computer science

Intro software enginnering

Answer 1

1)
The Five Workflows: Within the Unified Process, five workflows cut across the set of four phases: Requirements, Analysis, Design, Implementation, and Test. Each workflow is a set of activities that various project workers perform. The following subsections provide brief overviews of these workflows.

Requirements: The primary activities of the Requirements workflow are aimed at building the use case model, which captures the functional requirements of the system being defined. This model helps the project stakeholders reach agreement on the capabilities of the system and the conditions to which it must conform. The use case model also serves as the foundation for all other development work.

Analysis: The primary activities of the Analysis workflow are aimed at building the analysis model, which helps the developers refine and structure the functional requirements captured within the use case model. This model contains realizations of use cases that lend themselves to design and implementation work better than the use cases.

Design: The primary activities of the Design workflow are aimed at building the design model, which describes the physical realizations of the use cases from the use case model, and also the contents of the analysis model. The design model serves as an abstraction of the implementation model (see the next subsection). The Design workflow also focuses on the deployment model, which defines the physical organization of the system in terms of computational nodes.

Implementation: The primary activities of the Implementation workflow are aimed at building the implementation model, which describes how the elements of the design model are packaged into software components, such as source code files, dynamic link libraries (DLLs), and EJBs. Test: The primary activities of the Test workflow are aimed at building the test model, which describes how integration and system tests will exercise executable components from the implementation model. The test model also describes how the team will perform those tests as well as unit tests. The test model contains test cases that are often derived directly from use cases. Testers perform black-box testing using the original use case text, and white-box testing of the realizations of those use cases, as specified within the analysis model. The test model also contains the results of all levels of testing.

*****************************************

2)
For most software development projects, we can define five main risk impact areas:

1.New, unproven technologies

2.User and functional requirements

3.Application and system architecture

4.Performance

5.Organizational

1.New, unproven technologies: The majority of software projects entail the use of new technologies. Ever-changing tools, techniques, protocols, standards, and development systems increase the probability that technology risks will arise in virtually any substantial software engineering effort. Training and knowledge are of critical importance, and the improper use of new technology most often leads directly to project failure.

2.User and functional requirements: Software requirements capture all user needs with respect to the software system features, functions, and quality of service. Too often, the process of requirements definition is lengthy, tedious, and complex. Moreover, requirements usually change with discovery, prototyping, and integration activities. Change in elemental requirements will likely propagate throughout the entire project, and modifications to user requirements might not translate to functional requirements. These disruptions often lead to one or more critical failures of a poorly-planned software development project.

3.Application and system architecture: Taking the wrong direction with a platform, component, or architecture can have disastrous consequences. As with the technological risks, it is vital that the team includes experts who understand the architecture and have the capability to make sound design choices.

4.Performance: It’s important to ensure that any risk management plan encompasses user and partner expectations on performance. Consideration must be given to benchmarks and threshold testing throughout the project to ensure that the work products are moving in the right direction.

5.Organizational: Organizational problems may have adverse effects on project outcomes. Project management must plan for efficient execution of the project, and find a balance between the needs of the development team and the expectations of the customers. Of course, adequate staffing includes choosing team members with skill sets that are a good match with the project.
*********************************************

3)
Characteristics of Object Oriented programming language: 1.Encapsulation – Encapsulation is capturing data and keeping it safely and securely from outside interfaces. 2.Inheritance- This is the process by which a class can be derived from a base class with all features of base class and some of its own. This increases code reusability. 3.Polymorphism- This is the ability to exist in various forms. For example an operator can be overloaded so as to add two integer numbers and two floats.

4.Abstraction- The ability to represent data at a very conceptual level without any details. 5.Class definitions – Basic building blocks OOP and a single entity which has data and operations on data together 6.Objects – The instances of a class which are used in real functionality – its variables and operations

7.Abstraction – Specifying what to do but not how to do ; a flexible feature for having a overall view of an object’s functionality.

8.Generic classes – Class definitions for unspecified data. They are known as container classes. They are flexible and reusable.

9.Class libraries – Built-in language specific classes 10.Message passing – Objects communicates through invoking methods and sending data to them. This feature of sending and receiving information among objects through function parameters is known as Message Passing.
***************************************

4)

Definition: A (software/system) lifecycle model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities. It provides a fixed generic framework that can be tailored to a specific project.

Project specific parameters will include: • Size, (person-years) • Budget, • Duration

PROJECT PLAN = LIFECYCLE MODEL+ PROJECT PARAMETERS

There are hundreds of different lifecycle models to choose from, e.g: • waterfall, • code-and-fix • spiral • rapid prototyping • unified process (UP) • agile methods, extreme programming (XP) • COTS … but many are minor variations on a smaller number of basic models.

1.The Waterfall Model: The waterfall model is the classic lifecycle model – it is widely known, understood and commonly used. •In some respect, waterfall is the ”common sense” approach. •Introduced by Royce 1970. Advantages: 1. Easy to understand and implement.

2. Widely used and known (in theory!)

3. Reinforces good habits: define-before- design,design-before-code

4. Identifies deliverables and milestones

5. Document driven, URD, SRD, … etc. Published documentation standards, e.g. PSS-05.

6. Works well on mature products and weak teams. Disadvantages:

1. Idealised, doesn’t match reality well.

2. Doesn’t reflect iterative nature of exploratory development. 3. Unrealistic to expect accurate requirements so early in project

4. Software is delivered late in project, delays discovery of serious errors.

5. Difficult to integrate risk management

6. Difficult and expensive to make changes to documents, ”swimming upstream”.

7. Significant administrative overhead, costly for small teams and projects. 2.Code-and-Fix: This model starts with an informal general product idea and just develops code until a product is ”ready” (or money or time runs out). Work is in random order. Corresponds with no plan! (Hacking!) Advantages:

1. No administrative overhead

2. Signs of progress (code) early

. 3. Low expertise, anyone can use it!

4. Useful for small “proof of concept” projects, e.g. as part of risk reduction.

Disadvantages:

1. Dangerous!: a. No visibility/control b. No resource planning c. No deadlines d. Mistakes hard to detect/correct

2. Impossible for large projects,communication breakdown, chaos.

3.Spiral Model: Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: e.g. 1. Build some software 2. See if it meets customer requirements 3. If no goto 1 else stop. This loop approach gives rise to structured iterative lifecycle models.

In 1988 Boehm developed the spiral model as an iterative model which includes risk analysis and risk management. Key idea: on each iteration identify and solve the sub-problems with the highest risk. Each cycle follows a waterfall model by: 1. Determining objectives 2. Specifying constraints 3. Generating alternatives 4. Identifying risks 5. Resolving risks 6. Developing next-level product 7. Planning next cycle Advantages:

1. Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements

2. Flexible: incoporates the advantages of thewaterfal and rapid prototyping methods

3. Comprehensive model decreases risk

4. Good project visibility.

Disadvantages: • Needs technical expertise in risk analysis to really work • Model is poorly understood by nontechnical management, hence not so widely used • Complicated model, needs competent professional management. High administrative overhead. 4. Rapid Prototyping: Key idea: Customers are non-technical and usually don’t know what they want/can have Rapid prototyping emphasises requirements analysis and validation, also called: • customer oriented development, • evolutionary prototyping

Advantages:

1. Reduces risk of incorrect user requirements

2. Good where requirements are changing/uncommitted

3. Regular visible progress aids management

4. Supports early product marketing

Disadvantages :

1. An unstable/badly implemented prototype often becomes the final product.

2. Requires extensive customer collaboration – Costs customers money – Needs committed customers – Difficult to finish if customer withdraws – May be too customer specific, no broad market

3. Difficult to know how long project will last

4. Easy to fall back into code-and-fix without proper requirements analysis, design, customer evaluation and feedback.

5.Agile (XP) Manifesto: XP = Extreme Programming emphasises: • Individuals and interactions – Over processes and tools • Working software – Over documentation • Customer collaboration – Over contract negotiation • Responding to change – Over following a plan Agile Principles: • Continuous delivery of software • Continuous collaboration with customer • Continuous update according to changes • Value participants and their interaction • Simplicity in code, satisfy the spec XP Practices: • Programming in pairs • Test driven development • Continuous planning, change , delivery • Shared project metaphors, coding standards and ownership of code • No overtime! (Yeah right!) Advantages: • Lightweight methods suit small-medium size projects • Produces good team cohesion • Emphasises final product • Iterative • Test based approach to requirements and quality assurance Disadvantages: • Difficult to scale up to large projects where documentation is essential • Needs experience and skill if not to degenerate into code-and-fix • Programming pairs is costly • Test case construction is a difficult and specialised skill. 6.Unified Process: • Booch, Jacobson, Rumbaugh 1999. • Lifetime of a software product in cycles: • Birth, childhood, adulthood, old-age, death. • Product maturity stages • Each cycle has phases, culiminating in anew release (c.f. Spiral model) • Inception – identify core use cases, and use to make architecture and design tradeoffs. Estimate and schedule project from derived knowledge. • Elaboration – capture detailed user requirements. Make detailed design, decide on build vs. buy. • Construction – components are bought or built, and integrated. • Transition – release a mature version that satisfies acceptance criteria. 7. COTS: • COTS = Commercial Off-The-Shelf software • Engineer together a solution from existing commercial software packages usingminimal software ”glue”.

• E.g. using databases, spread sheets, word proccessors, graphics software, web browsers, etc. Advantages: • Fast, cheap solution • May give all the basic functionality • Well defined project, easy to run Disadvantages:

• Limited functionality•Licensing problems, freeware, shareware, etc. • License fees, maintainance fees, upgrade compatibility problems