ASSIGNMENT 5B

TEAM ID 29

SIDDHARTH GOYAL – 201064049,

SHRIYAA MITTAL – 201064056,

NITISH ALODIA – 201064062,

ANUBHAV CHATURVEDI – 201064094,

SRICHARAN THOTA – 201064120

1.5

The seven categories of software are as follows:

1. System Software

2. Application Software

3. Engineering/Scientific Software

4. Embedded Software

5. Product-line Software

6. Web Applications

7. Artificial intelligence Software

All of these are similar in nature and yet, have special features associated with each of them.

For instance web applications are unique in terms of network intensiveness, concurrency,

unpredictable load, availability, data driven, content sensitive, continuous evolution,

immediacy and security.

But, the same approach to software engineering can be applied to each of them keeping in

view the category the software to be constructed belongs.

It is imperative to identify the stakeholders involved and communicate with every one of

them to consider the requirements, opinions and ideas of all. Else, the end-product would not

be of good quality and would end up being redundant. A project-plan must be made which

defines the tasks to be conducted the, technologies to be used, risks involved, resources

required and a schedule of the work. All categories of softwares would require that every task

to be executed by the final product is modelled taking into account the nitty-gritties of the

requirements. This could be done by specifying use-cases and developing UML diagrams.

Coding is another aspect of software engineering and, probably the most tempting one for

any software developer. It should be noted that the codes are robust and modular. They must

also have the capability to be adaptive to changes in the future. The conclusive and the most

important step is delivering the software to the customer. This could be done periodically or

just once on completion depending on the specifications in the work schedule.

Thus, the details of the software process will vary from one category to another but, the

framework will always remain same.

2.7

The waterfall model suggests a systematic sequential approach to software development that

begins with customer satisfaction -

The three software projects that would be amenable to waterfall model will be -

1. A well-understood modification to an existing program

2. A straightforward implementation of a numerical calculation or business rule, even if

it is complex.

3. A constrained enhancement to an existing program

2.10

The Three software projects that would be amenable to incremental process model will be -

1. A project that has significant functionality that must be delivered in a very tight time

frame.

2. Movie playing softwares which can start with basic functionality like playing movie

and listening to music, but can be developed further to include plugins for playing

new formats and better visualisations.

3. Text editing programs, which can be started with basic applications for typing,

deleting, copying and pasting text, but can be developed to include new fonts, spell

checking, inserting pictures, word art, text and background colours etc.

3.2

As it is often said 'The only thing that is constant is CHANGE'. The same applies to Software

development too. Thus software developers must always be on their toes to accept and adopt

changes, instead of evading them. The changes could be in the software being built, the team

members, the work environment or changes due to a new technology.

Agility is more than an effective response to change in the following manner:

Self-organization and motivation are required, team work and communication between group

members is essential.

Working software will be more useful and welcome than just presenting documents to clients

in the meetings.

Requirements cannot be fully collected at the beginning of the software development cycle,

therefore, continuous customer or stakeholder involvement is very important. But, the

distinction between 'us' and 'them' is not there.

Agile development is focused on quick responses to change and continuous development.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair

programming, test driven development, design patterns, domain-driven design, code

refactoring and other techniques are often used to improve quality and enhance project

agility.

3.3

In various situations the initial requirements of the software are well defined, but then also

the overall development effort follows a purely linear process. Also, there might be a demand

to make software with limited functionality for some users and to quickly refine and expand

the functionality in later releases. These are the cases where incremental process is

appropriate to use. In other words the incremental or the ITERATIVE process allows proper

evolving of the desired software keeping in view the change of requirements of the users. So

the iterative process makes it easier to manage change. This is also true because the current

release serves as the starting point of the next release and also required changes can be made.

Yes every agile process described in the chapter is iterative because the software is developed

in view of all the changes and also with the goal of going forward to deliver the final

software.

No, it is not possible for a process to complete a project in just one iteration and still be agile

because then no changes will be considered after the iteration thus contradicting agile view of

the process which suggests that the software development team responds appropriately to any

changes suggested by the user.

4.3

“Separation of concerns” Here refers to analysis and design of a software system when done

through a method called “Divide and Conquer” . In this method, we tend to separate the

various problems referred to in the software system and conquer each one of them.

Separation of Concerns (SoC) is the process of separating a computer program into distinct

features that overlap in functionality as little as possible. A concern is any piece of interest or

focus in a program. Typically, concerns are synonymous with features or behaviours.

Progress towards SoC is traditionally achieved through modularity of programming and

encapsulation (or "transparency" of operation), with the help of information hiding. Layered

designs in information systems are also often based on separation of concerns (e.g.,

presentation layer, business logic layer, data access layer, database layer).

Ideally, Each concern delivers distinct functionality that can be developed, and in some cases

validated, independently of other concerns.

4.9

A Project plan is always iterative. The requirements of the mentors keep changing leading to

the change in the project plans and the product. Hence the plan must be adjusted to

accommodate these changes. In addition, iterative, incremental process models dictate

replanning after the delivery of each software increment based on feedback received from

users.

Iterations lead to changing the system functionality into increments (portions). In each

increment, a slice of functionality is delivered through cross-discipline work, from the

requirements to the deployment. The unified process groups increments/iterations into

phases: inception, elaboration, construction, and transition.

Inception identifies project scope, risks, and requirements (functional and non-

functional) at a high level but in enough detail that work can be estimated.

Elaboration delivers a working architecture that mitigates the top risks and fulfils the

non-functional requirements.

Construction incrementally fills-in the architecture with production-ready code

produced from analysis, design, implementation, and testing of the functional

requirements.

Transition delivers the system into the production operating environment.

Each of the phases may be divided into 1 or more iterations, which are usually time-boxed

rather than feature-boxed. Architects and analysts work one iteration ahead of developers and

testers to keep their work-product backlog full.

Hence the Project plan is always Iterative.

4.14

I disagree with the statement “ Since we deliver multiple increments to the customer, why

should we be concerned about the quality in the early increments- we can fix problems in the

later iterations.”

I disagree to this statement because

1. Each increment builds on the next and no one wants to build on a low quality foundation.

2. If the first increments are low in quality, customers and users may become concerned

(about the competence of the team); unnecessary tension may develop, and follow-on

communication suffers.

We should understand it form the quote which says

“

Quality is built in to the product from the beginning, not some afterthought applied right

at the end.”

5.2

The first step in software engineering is to understand the problem, the people who want the

solution, nature of the solution desired and the need to communicate with different

stakeholders.

Next, is to ask the customer, the user and others, the objectives and their expectations from

the product. It is a key step towards building the software. If it is not carried out or is done so

in a jiffy, the end-product will not be what the end-users wanted and thus, of no use. It may

lead to a lot of changes once you have begun coding which is not an advisable situation.

Also, it would lead to delays and inability to deliver the product on time according to the

work schedule.

Sometimes, it may happen that the customer is busy and is unable to meet the requirements

engineer, i.e. us in this case. It is not desirable, but, may happen. In such a scenario, the role

of the requirements engineer becomes that he identifies the stakeholders, meets up all of

them, except the customer, who is too busy to do so and derives an understanding of the

problem and the solution from them as much as possible. Next, he may prepare the

SRS(Software Requirements Specifications) document and then send it to the customer for a

review. This way the customer will not have to start from scratch with the requirements

engineer and already has something to go upon.

Also, if the issue is that the customer is busy to meet physically, then, virtual meetings can

also conducted for example, on the phone, e-mail, chat, Skype etc.

6.6 (a)

Pothole location: The location in the street of the pothole. The places allowed are near the

curb, and near the middle of the street.

Pothole repair state: The condition of the pothole in terms of what stage of repair it is in. The

states of the pothole: not repaired, work in progress, temporary repair, and repaired.

The scale of a pothole: A ranking, on a scale of one to ten, of the size of a pothole.

The Pothole Tracking and Reporting System (PHTRS) provide a way for citizens of a large

city to report potholes and to report damage they have experienced as the result of a

pothole. The PHTRS keeps track of the potholes and damage and creates work orders for

repair crews. The repair crews use the PHTRS to record information about their effort to

repair potholes. Authorized users of the system can receive a report on potholes and their

repair status and on reported damage.

The PHTRS is an on-line, web-based system.

PHTRS users are from all walks of life, all backgrounds, and all levels of computer literacy

found in the citizenry of a large city. They are expected to be familiar with web browsers and

filling out on-line forms.

Use Cases

The PHTRS supports the following uses:

Report a Pothole: A citizen reports the location and size of a pothole. The PHTRS records

this information.

Report Damage: A citizen reports damage due to a pothole. The PHTRS records damage

information and citizen contact information.

Get Work Orders: Work crews receive pothole repair work orders. The PHTRS determines

the number of people in a repair crew, the equipment assigned to the repair crew, and the

potholes the crew is to repair.

Record Repairs: Work crews report the status of pothole repairs they have performed and

the amount of time and materials used on the repairs. The PHTRS records this information.

View Pothole and Damage Reports: Authorized users of the PHTRS view information on

potholes and their repair and on reported damage.

Actors:

Citizens can report potholes and report damage. The citizen initiates this use of the PHTRS.

Work crews can get work orders for potholes needing repair and can record information

about the pothole repair work they have done. A representative of a work crew initiates this

use of the PHTRS.

An authorized user of the PHTRS can view pothole reports and damage reports. The

authorized user initiates this use of the PHTRS.