Sei sulla pagina 1di 7

ASSIGNMENT 5B

TEAM ID 29

SIDDHARTH GOYAL SHRIYAA MITTAL NITISH ALODIA

201064049, 201064056, 201064062, 201064094, 201064120

ANUBHAV CHATURVEDI SRICHARAN THOTA

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 nonfunctional) 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.

Potrebbero piacerti anche